Re: gPXE scripts and boot module order

On Thursday 13 August 2009 12:11:41 Stefan Hajnoczi wrote:
> Here is a theory:
>
> When gPXE downloads an image, memory is handed out from the top of
> memory towards lower addresses.  The first image you download will
> have a higher memory address than the second image you download.
> (Details: core/downloader.c uses urealloc() to reserve memory for the
> image being downloaded, arch/i386/interface/pcbios/memtop_umalloc.c
> implements the umalloc() heap by growing it downwards.)
>
> The multiboot code in gPXE will sort modules in ascending memory order
> for OS compatibility reasons, therefore the last module you downloaded
> is first in the list.  (Details: You will see a comment in
> arch/i386/image/multiboot.c that says:
> /* At least some OSes expect the multiboot modules to
>  * be in ascending order, so we have to support it.
>  */)

All correct.  It's arguable that we should change the behaviour so that 
instead of sorting the module list in-situ, we should copy them down below 
the umalloc()ed area so that we can present the loaded OS with a list of 
modules that are both in ascending order (which is needed for some OSes) and 
also in load order (which would avoid surprising users in this way).

The downside of doing this is that it would break any existing setups using 
gPXE's multiboot loader, since those setups must already be reversing the 
module order.  We could mitigate this problem by bumping the version number 
for our multiboot support to

  FEATURE ( FEATURE_IMAGE, "Multiboot", DHCP_EB_FEATURE_MULTIBOOT, 2 );

I'm open to argument either way.  Thoughts?

Michael

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july