| Age | Commit message (Collapse) | Author |
|---|
|
Linker does not provide some vital functions when building freestanding
applications with a new toolchain, so we have to provide our own CRT.
p.s.
Without the CRT we won't see any build errors (since the purgatory is
linked with --no-undefined), but the purgatory code won't work,
'kexec -e' will just hang the board.
I added option to configure to keep code buildable for old toolchais.
But there should be way to do this automatically.
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some code dtb scanning & filling has been borrowed from ppc64.
The old behavior is still available if compiled with GameCube,
other PowerPC platform use the can purgatory and specify a new
dtb.
Booting a self contained elf image (incl. dtb / without the need
for a bd sturct or the like) can be booted. The dtb support is currently
optional. That means if the elf image does not contain a dtb file then
the user has to supply a complete dtb (including mem size, command line,
bus freq., mac addr, ...)
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
x86_64 specific support, including crash memory range and purgatory setup.
Corresponding kernel support has been merged already.
Together with the kexec jump features in Linux kernel, kexec jump can
be used for following:
- A simple hibernation implementation without ACPI support. You can
kexec a hibernating kernel, save the memory image of original system
and shutdown the system. When resuming, you restore the memory image
of original system via ordinary kexec load then jump back.
- Kernel/system debug through making system snapshot. You can make
system snapshot with kexec/kdump, jump back, do some thing and make
another system snapshot.
- Cooperative multi-kernel/system. With kexec jump, you can switch
between several kernels/systems quickly without boot process except
the first time. This appears like swap a whole kernel/system out/in.
- A general method to call program in physical mode (paging turning
off). This can be used to invoke BIOS code under Linux.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to serial
console/VGA while executing the purgatory code. Implement this feature for
POWERPC pseries platform by using the H_PUT_TERM_CHAR hypervisor call by
printng to hvc console.
Includes the changes suggested by Michael Ellerman
Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The kernel updated its ABI to tell the relocatable kernel to run
where it was loaded.
We now need to set a flag in the kernel image. Since we only have
the kernel image avialable as const data to kexec-tools c code, set
the flag in the copy we put in purgatory, and have it set the flag
in the kernel (after purgatory has run its checksum). To simplfy
the purgatory code we can always copy the flag word back to the
kernel as the c code made a copy of the original flag value.
Signed-off-by: Milton Miller <miltonm@bga.com>
Tested-by: M. Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
gcc complains because x86_setup_jump_back_entry() has no arguments,
making the argument list void resolves this.
Also, make the function static as it isn't used in any other files.
And move the function above where it is used, to eliminate the
need for a forward-declaration.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix a bug of kexec load on x86_64. Kexec fails to do load on x86_64, with
error message:
Symbol: cmdline_end not found cannot set
Because kexec/arch/i386/kexec-bzImage.c accesses cmdline_end symbol in
i386 purgatory, but there is no cmdline_end in x86_64 purgatory, and
kexec-bzImage.c is used by x86_64 too.
cmdline_end is added into x86_64 purgatory to solve the bug, because kexec
jump support for x86_64 is planned.
Reported-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
To support memory backup/restore an option named
--load-preserve-context is added to kexec. When it is specified
toggether with --mem-max, most segments for crash dump support are
loaded, and the memory range between mem_min to mem_max which has no
segments loaded are loaded as backup segments. To support jump back
from kexeced, options named --load-jump-back-helper and --entry are
added to load a helper image with specified entry to jump back.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Relocatable kdump kernel support in kexec-tools
This patch adds relocatable kernel support for kdump in the kexec-tools
code. A signature (0xfeed1234) is passed in r6 from panic code to the
purgatory code through kexec_sequence function. The signature is used to
differentiate between relocatable kdump kernel and non-kdump kernels.
The purgatory code compares the signature and sets the __kdump_flag in
head_64.S by using the offset with respect to next kernel load address.
During the boot up, kernel code checks __kdump_flag and if it is set, the
kernel will behave as relocatable kdump kernel.
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As pointed out by Edgar E. Iglesias, the -fno-zero-initialized-in-bss
option to gcc is not available in the cris 3.2.1 toolchain.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The EFI Runtime Services Table contains pointers to ia64 function
descriptors. On existing, pre-Tiano, firmware, SetVirtualAddressMap()
converts *all* these pointers from physical to virtual. On Tiano-based
firmware, the pointer to the SetVirtualAddressMap() function descriptor
is not converted, so it remains a physical pointer.
The ia64 kexec purgatory patches the SetVirtualAddressMap() function
descriptor so that when the new kernel calls SetVirtualAddressMap(), it
never reaches firmware. Instead, it calls a dummy function that just
returns success.
Purgatory runs in physical mode, so it must convert the pointer from the
RuntimeServicesTable to a physical address. This patch makes that
conversion work both for old firmware (where the pointer is an identity-
mapped virtual address) and new Tiano firmware (where the pointer is a
physical address).
Without this patch, kexec on Tiano firmware causes an MCA because
ia64_env_setup() subtracts PAGE_OFFSET from a physical address and ends
up with an invalid physical address. Referencing that address causes
the MCA.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes following compiler warning:
purgatory/arch/i386/console-x86.c:84: \
warning: implicit declaration of function `outb'
purgatory/arch/i386/console-x86.c:89: \
warning: implicit declaration of function `inb'
Found on x86_64. The problem did not happen with i386.
Fix tested on x86_64-suse-linux and i586-suse-linux.
I also added __always_inline__ to make sure that the function gets always
inlined, regardless of optimisation compiler flags.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The generated code is byte-for-byte identical.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The entry16 and entry16_debug functions need to compute appropriate 16-bit
segments before dropping to real mode. Each is intended to use its own
entry address as the segment base. However, both were using the entry
address of entry16_debug, causing the code-segment reload to branch to the
wrong place in the non-debug case.
This bug was only visible when running kexec with --real-mode and without
--debug.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The undefined symbols naturally weren't relocated by kexec's linker, so
each compiled `call` instruction branched into the middle of itself. The
CPU proceeded to interpret the un-relocated address as instructions,
resulting in an undefined opcode fault. Since at this point no IDT is
loaded, that turned into a triple-fault and reboot.
The bug was only visible when running kexec with --console-vga.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently, CPPFLAGS and LDFLAGS can 'leak' into the purgatory build
from the main kexec/kexec object. Because of this, the purgatory
is build with -lz, but we may not have a zlib present for the
architecture of the purgatory object.
This change uses fresh CPPFLAGS and LDFLAGS for the purgatory object.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
From: Simon Horman <horms@verge.net.au>
Fix a typo and distribute $(mips_PURGATORY_SRCS) instead of
$(mips_PURGATORY_C_SRCS) as the latter is empty.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Sometimes I write nonsensical notes. When I wrote the comment
in purgatory/arch/x86_64/Makefile it was one of those times.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes kexec-tools on x86_64. The build had two problems:
1. The distribution missed the files
purgatory/arch/x86_64/entry64-32.S,
purgatory/arch/x86_64/entry64.S,
purgatory/arch/x86_64/setup-x86_64.S,
purgatory/arch/x86_64/stack.S,
purgatory/arch/x86_64/purgatory-x86_64.c
The problem was that variable expansion in a Makefile is a bit different
from the expectation, i.e. the final value is used even if the variable is
used in the middle.
2. The build didn't include the files mentioned above. This was because of
using '=' instead of '+=' in the 2nd part of the Makefile.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mips/include/limits.h from distribution
as it no longer exists.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
[ Reposted with correct linux-mips address ]
Hi,
this patch switches the mips support in kexec-tools around a little bit.
All the files and directories containing "mipsel" have been renamed
to contain "mips" instead.
This is kind of consistent with the way that ARCH=mips in the kernel
works for both big and little endian.
After a small amount of tweaking, which is also included in this patch, the
code compiles and works fine for big endian mips as well as small endian
mips. All you need to do is compile using an appropriate compiler.
That is to say, kexec-tools's build system doesn't need to
be told about which endienness the code is being compiled for.
I have added kept mipsel as a supported "architecture" via ./configure,
though its just an alias for mips now. This is consistent with how
other architectures such as sh are treated. But I'm happy to remove
mipsel from ./configure if the mips people want that.
I tested this patch using qemu and the 2.6.24.3 tag of the mips-2.6 git
tree compiled for the qemu machine type for both big and little endian.
The qemu machine type has subsequently been removed, and kexec-tools
needs some work in order to function with qemu - as far as I understand
the way the boot parameters are passed needs to be fixed, likely
in purgatory. However, this is not related to the changes
introduced in this patch.
I intend to merge this patch into kexec-tools-testing if
no alarm bells are sounded.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
While trying to test latest kexec tools git code on a x86_64
box i ran into following issue. Kexec refused to load both
kexec and kdump kernels.
# ./build/sbin/kexec -l /boot/vmlinuz-2.6.25-rc5 --initrd=/boot/initrd-2.6.25-rc5
Symbol: entry32_regs not found cannot get
#
# ./build/kexec -p /boot/vmlinux-kdump --initrd=/boot/initrd-kdump
--append="...."
Symbol: entry64_regs not found cannot get
#
It turns out that entry64.S file under purgatory/arch/x86_64 was not
compiled. The original x86_64_PURGATORY_SRCS were being overwritten
in the Makefile.
Signed-Off-By: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mipsel/include/limits.h as it is not needed.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mipsel/include/stdint.h as it just duplicates
things found in system header files.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hello,
We developed a patch to port kexec-tools to mips arch and included support for
command line passing through elf boot notes.
We did it for a customer of ours on a specific platform derived from toshiba
tx4938 (so we think it should work at least for tx4938 evaluation board also).
We would like to contribute it in case somebody else needs it or wants to
improve it.
This patch works for us but the assembler part in particular, should be
considered as a starting point because my assembly knowledge is not too deep.
As this is the first time I submit a patch I tried to guess reading tpp.txt if
this is the right way to submit. Please let me know about any mistakes I may
have made.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
From my observations the way that the EFI_LOAD_DATA is provided
on the inital boot works like this:
There is a large EFI_CONVENTIONAL_MEMORY region.
The portion begining at the first load segment of
the image to be loading and ending with the last segment,
aligned to 64K, is turned into a separate region
of type EFI_LOAD_DATA.
A truncated example of this:
...
mem04: type= 7, attr=0x0000000000000008, range=[0x0000000000100000-0x0000000004000000) ( 63MB)
mem05: type= 2, attr=0x0000000000000008, range=[0x0000000004000000-0x000000000481f000) ( 8MB)
mem06: type= 7, attr=0x0000000000000008, range=[0x000000000481f000-0x000000003e876000) ( 928MB)
...
Where type 7 is EFI_CONVENTIONAL_MEMORY and
type 3 is EFI_LOAD_DATA.
There is a patch to the user-space portion of kexec-tools that merges the
segments supplied to this code if they are adjacent. This seems to always
result in a single segment being passed to this code, that should start
at the same address as the existing EFI_LOAD_DATA segment.
So all that should be left to do is to merge the existing
EFI_LOAD_DATA region with the following EFI_CONVENTIONAL_MEMORY region,
and then split it up to accommodate the segment passed from user-space.
The new EFI_LOAD_DATA region created with this code will always
start at the same address as the old EFI_LOAD_DATA region. If
this proves to be overly simplistic it should be easy to update.
This code also allows merging of multiple regions to accommodate
the new EFI_LOAD_DATA region. I strongly doubt this will ever
be used, but it is in line with the way the existing code works.
If the same image is used after kexec, then the
EFI regions in question will turn out the same as the original regions.
This is important, otherwise kernel / hypervisor regions will not be able
to be inserted into /proc/iomem / /proc/iomem_machine.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes following compilation warning:
purgatory/purgatory.c:21: warning: passing argument 2 of 'sha256_update' makes pointer from integer without a cast
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With the recent build changes a number of unneded files
crept into tarballs, including .o and .d files.
This patch is farily verbose, but hopefully in the long
run this system will be obvious enough to be maintainable.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Pugatory files need to be linked with the target linker,
not the build linker.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add ARM support to kexec including commandline support through ATAGs.
The kernel syscall support has already been merged and kernel ATAG
exporting is queued for 2.6.25 (its optional for kexec).
Based on work by various people, notably Uli Luckas <u.luckas@road.de>
for adding ATAG support.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use a $(clean) variable to store all items that need to be removed on
'make clean' (eg, .o files).
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
Conflicts:
Makefile.in
|
|
Since we use the implicit ruls for .c and .S, just colelct all sources
in the one variable.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Purgatory seems to partially duplicate system headers.
It seems a log cleaner not to do so.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This change makes kexec-tools work more like a standard configure-make-
make-install-type project:
* Remove $(OBJDIR) stuff. To do an out-of-tree build, just configure
from a different directory.
* Use the implicit Makefile rules more, and just edit the compiler
flags for specific targets.
* Simplify compiler/linker flags - no need for EXTRA_*
* Add TARGET_CC, and improve checks for BUILD_CC too.
* Set arch-specific flags in arch-specific makefiles, not conditional
on $(ARCH).
* Generate dependency files in the main compile, rather than as a
separate step.
* Don't #include sha256.c, but re-build it into the purgatory.
Still a work-in-progress.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Based on
http://cvs.fedora.redhat.com/viewcvs/rpms/kexec-tools/devel/kexec-tools-1.101-ppc-boots-ppc64.patch?rev=1.2&view=auto
64 bit: OK
32 bit: purgatory build fails
Work-in-progress-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Purgatory doesn't really care about the SMP cpus. But if we leave them
behind, they end up getting lost when the kernel overwrites purgatory or
the previous kernel. The current slave handling in purgatory doesn't
have any handshaking to make sure the cpus have moved on before leaving.
Instead of moving the slave cpus up to purgatory and then back down to
the kernel, just copy bytes 4-255 from the kernel and use it as the
purgatory start / slave hold block.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The address where the ELF core header is stored is passed to the secondary
kernel as a kernel command line option. The memory area for this header is
also marked as a separate EFI memory descriptor on ia64.
The separate EFI memory descriptor is at the moment of the type
EFI_UNUSABLE_MEMORY. With such a type the secondary kernel skips over the
entire memory granule (config option, 16M or 64M) when detecting memory.
If we are lucky we will just lose some memory, but if we happen to have data
in the same granule (such as an initramfs image), then this data will never
get mapped and the kernel bombs out when trying to access it.
So this is an attempt to fix this by changing the EFI memory descriptor
type into EFI_LOADER_DATA. This type is the same type used for the kernel
data and for initramfs. In the secondary kernel we then handle the ELF core
header data the same way as we handle the initramfs image.
This strategy requires changes in the secondary kernel as well, I'll
post the kernel patches in a little while.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Patch found on
http://eggplant.ddo.jp/www/download/debian26/source/kexec-tools/kexec-tools_1.101-2sh.diff.gz
According to Paul Mundt <lethal@linux-sh.org> it was originally by
kogiidena <kogiidena@eggplant.ddo.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Magnus Damm <magnus.damm@gmail.com>
|
|
Hi,
I've run into problems testing kexec/kdump on a Montecito revision C
processor. In purgatory, __dummy_efi_function is copied onto the end of
the command line boot parameter (command_line + command_line_len) and this
address is used to replace the EFI call to set_virtual_address_map(). The
copied range is then icache flushed.
The destination address is aligned to 16-bytes (in kexec-elf-ia64.c), but
the fc.i instruction flushes a 32-byte range "associated" with that
address. When my command line length is 16-byte aligned but not 32-byte
aligned, this results in the first 16-bytes of __dummy_efi_function getting
flushed (and the 16 bytes prior to that), but the second half of the
function (the part with the br.ret) does not get flushed. kdump then hangs
in purgatory. By adding a few spaces to my command line, it becomes both
16 and 32-byte aligned, and kdump works.
This patch makes icache_flush_range() align the start address to 32-bytes
and account for the difference. The patch is against Horms
kexec-tools-testing tree. As a side note, you could also fix this by just
adding 32 to the length passed to flush_icache_range() but that hides the
dependent behavior.
Thanks,
-T
It seems I was always testing with command line more than 16 bytes
length.....
Thanks.
Acked-by: Zou Nan hai <nanhai.zou@intel.com>
Manually applied - not sure why that was neccessary.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This adds vmm support to kexec-tool for ia64. This is annalogous
to the same feature that is present in the latest version of elilo.
It is a method of booting a vmm (hypervisor) such as Xen.
Essentially it works as follows.
* If the --vmm argument is not provided, then the kernel is booted as normal,
no changes
* Else, the image specified by --vmm is placed loaded into the elf
segments, where the Linux kernel image would otherwise have gone.
And the Linux kernel image, allong with its length is loaded into a
seprate segment, and passed as new entry at the end of the boot parameters.
This is somewhat similar to how initramfs/initramd images are passed
to a booting kernel, and can work in conjunction with that feature.
On boot (or in this case on kexec) the vmm (hypervisor) will be
loaded instead of a Linux kernel, and the hypervisor will then load up
the Linux kernel as it sees fit.
This is needed in order for kexec from Xen to Xen, using the
port of kexec to Xen that I am working on, to work.
I am not entirely fond of this design, and i think that developing
an ia64 variant of multiboot would be much nicer. However it is
an existing method that is currently in widespread use through
its incarntation in elilo. And if multiboot is added in future,
it can be done as a separate boot method, and thus orthogonal to this
patch.
In order to use this code a number of other changes are needed,
in particular:
1. Xen and the corresponding Linux Kernel needs to be patched with
the port of kexec to ia64-xen that I have been working on.
I will post the latest version of these patches to xen-devel
shortly.
2. The currently hardcoded PAGE_OFFSET value in purgatory needs
to be changed from the Linux value to the Xen value. I will
post a very hackish, definately not to be released, patch
after this patch which includes a comment that explains this problem
more clearly.
Also, xen->linux and linux->xen is still very much work in progress due
to the problem described at the following link
http://permalink.gmane.org/gmane.linux.ports.ia64/14995
However, from an infastructure point of view I think it would be good to
apply this code, so that kexec-tool is one step closer to being able to
support vmms (hypervisors). The patch does not alter any existing
behaviour, it just adds a new feature. Bugs asside, the only real danger
seems to be confusion for end-users, perhaps we could comment out the help
text to hide the feature from the lay user, or attach a big fat warning to it.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
[BUILD] CPPFLAGS, CFLAGS and LDFLAGS fixes
* Set internal CPPFLAGS as EXTRA_CPPFLAGS, CFLAGS as EXTRA_CFLAGS,
and LDFLAGS as EXTRA_LDFLAGS
- Don't overwrite CPPFLAGS, LDLFAGS or CFLAGS from the environment
- They are irrelevant for BUILD_CC
- When cross-compiling for a ppc64 host on a non-ppc64 host,
EXTRA_CFLAGS, which is included in BUILD_CPPFLAGS contains
-mcall-aixdesc, which does not work on i386 at least
* Use LDFLAGS when linking kexec
- Append rather than overwrite in purgatory/Makefile
The purpose of these changes is three-fold.
* CPPFLAGS, CFLAGS and LDFLAGS from the environment really ought
to be honoured. For one thing;
* Without these changes, the confgiure taget in
the toplevel makefile can't work
* Without these changes, cross compiling does not work -
well, I can't work out how to get it to work anyway.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Add a more verbose comment to explain why set_virtual_address_map is
replaced why a dummy function
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This unifies the comments in purgatory-ia64.c to always use C style
comments. Previously some comments where C style, while others were
C++ style.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This makes the tail of patch_efi_memmap() slightly less nested,
and thus a little easier to read.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Just use boot_param->efi_memdesc_size directly instead, it seems
at least as clean, and possibly easier to follow.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
len is assigned once and used once, just use boot_param->efi_memmap_size
directly instead.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
