[gPXE-devel] [PATCH v3][lkrn] add ramdisk support

[Wu Fengguang]

On Thu, Jun 03, 2010 at 05:57:33PM +0800, Michael Brown wrote:
> On Thursday 03 Jun 2010 08:32:55 Wu Fengguang wrote:
> > > You are right.  We need a clean way to pass the off-limits region to
> > > relocate().
> > >
> > > Generic code can't access lkrnprefix.S symbols but it should be
> > > possible to pass an (addr, size) pair or even a pointer to an array of
> > > (addr, size) pairs.
> > 
> > Yes! This is actually what I've been thinking: a little less
> > straightforward, however a more modular approach.
> 
> Do you see anything wrong with Shao Miller's approach:
> 
>   http://git.etherboot.org/?p=people/sha0/gpxe.git;a=commitdiff;h=e9516971
> 
> It's pretty straightforward, and solves the problem.

I guess the main difference between the two approaches are, one takes
care not to make any assumption about the ramdisk location/size (still
leaves out HIGHMEM_LOADPOINT though), while the other takes the good
KISS attitude.

As far as I know, GRUB and PXELinux both loads ramdisk to the highest
allowed address. For them Shao's code works just OK. (There is still
theoretical possibility for umalloc to overwrite ramdisk region, but I
don't regard it as practical issue.) I would vote for the simplicity
of Shao's patch if I'm sure that all relevant boot loaders are as safe
as GRUB. So expecting some experts' viewpoint in this area.

> The only reason I haven't yet merged it in to iPXE is because I'm
> wondering if there's a way to (neatly) pass max_addr in via a
> register, as is done with all other parameters in the prefix code.
> 
> (The problem of using memory for parameter passing is that the ROM prefix 
> sometimes executes with a read-only .prefix.  Consequently all of the generic 
> prefix code is written to assume that .prefix is non-writeable.  While it's true 
> that the ROM prefix wouldn't need to override max_addr, I'd prefer to avoid 
> introducing that kind of inconsistency.  We could pass parameters via the 
> stack but, again, that would introduce an inconsistency since currently 
> everything is passed in registers.)

I'm not expert, just sharing a wild idea: what if we introduce a
.data16.copy section that is part of .data16, except that it's copied
(instead of uncompressed) to new location? This should allow various
prefixes to convey values to the latter stages conveniently. This also
decouples libprefix from any domain specific variables.

Thanks,
Fengguang