Re: RFC: x86: relocatable kernel changes (revised spec)

Eric W. Biederman wrote:

+Field name: init_size
+Type: read
+Offset/size: 0x25c/4
+
+ This field indicates the amount of linear contiguous memory starting
+ at the kernel load address (rounded up to kernel_alignment) that the
+ kernel needs before it is capable of examining its memory map. This
+ is not the same thing as the total amount of memory the kernel needs
+ to boot, but it can be used by a relocating boot loader to help
+ select a safe load address for the kernel.

This wording is a bit unclear.

Can we finally say that it is safe to put the initrd immediately after
the kernel?


I *believe* we can, as the brk limit checking should catch overruns.
The only question is whether or not there will me memory allocated off
the memory map before the initrd is reserved; I *think* the answer is no
but I haven't done the audit.

The rounding up part of that comment is unclear.

The rounding up was to reflect the automatic moving upwards from the
load address to the next kernel_alignment datum.

Peter did your implementation of init_size take into account the maximum expansion
during decompression? At a quick glance at your previous patches I couldn't
tell. I know were in that direction with zoffset.h and voffset.h but I don't
recognize the formula for where I put the pic decompressor in your calculation
of this.

It does take it into account. The pic decompressor is located at
(ZO_)z_extract_offset; the actual formula moved into mkpiggy.c.

I have regenerated the tip:x86/kbuild-phys branch to be only cleanups
(with the intent of putting the policy changes cleanly on top), and much
better structured. I hadn't originally expected this to turn into so
much of a cleanup effort.

http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=shortlog;h=x86/kbuild-phys

This checkin, in particular, should answer that question, I believe:

http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=02a884c0fe7ec8459d00d34b7d4101af21fc4a86

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [opensuse] unable to access website after 10.2 install [CLUE!]
    ... Its not the native kernel for that hardware. ... And the 64bit address registers, ... etc also load in the same number of clocks as the 32 bit ... everything places on the memory subsystem. ...
    (SuSE)
  • Re: Device Drivers and Kernel Modules
    ... got confused in my memory. ... between the drivers in the kernel opposed to loaded kernel modules. ... > drivers through compiling them into the kernel or to load them at boot ... > I have also heard that loading modules through the loader.conf saves on ...
    (freebsd-questions)
  • Re: Device Drivers and Kernel Modules
    ... drivers through compiling them into the kernel or to load them at boot ... wuld not require a rebuild of the kernel. ... From memory it stated modules such ... Loading a module really does load it into memory. ...
    (freebsd-questions)
  • Re: knowing kernel memory usage
    ... You could subtract the amount of memory shown by free from the amount you ... > the amount of memory allocated by userspace processes. ... kernel all the time. ...
    (comp.os.linux.development.system)
  • Re: ICH9 & Core2 Duo - kernel crash
    ... I am trying LKML to get some help on one linux kernel related problem. ... No kernel crashes no problems, ... I have seen unusual memory behavior under heavy load, ... The problem with memtest, unless I underestimate it, is that it doesn't use all core and siblings, so it doesn't quite load the memory system the way regular usage would. ...
    (Linux-Kernel)