Re: [Etherboot-developers] [CFT][RFC] Linux kernel boot cleanup.

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >There are a couple of approaches to this problem.
> >1) mknbi still works.  All of my changes are backwards compatible.
> >   mknbi can now (potentially) do a better job as higher quality
> >   information is available, but from that perspective it is the only
> >   significant change. 
> >
> >   In particular my current ELF images will not work on a system
> >   with a DOC millenium.  
> 
> A interim solution might be to teach mkelf-linux about the new kernel
> Elf format. It should be transparent, the Perl code would detect the new
> format and do the right thing. 

Since all you have to do is strip a ~= 333 byte header off to get a 
bzImage that should be simple.  

> It would accept a kernel Elf and spit out
> a netbootable Elf, the only difference being that a third stage stub
> gets control first to parse the DHCP options and inject the relevant
> ones into the command line. And so long as the kernel cannot handle
> appended initrds, the stub would copy the initrd to the top of memory.
> 
> When the code goes into 2.5 I might hack mkelf-linux.

Right there is no point doing anything before then.
 
> Users who don't need to extract options from DHCP or append initrds
> could just use the kernel Elfs directly.

Correct.
 
> >2) We can teach the kernel about etherboot specifically and let it
> >   pick the command line out the dhcp options etherboots passes.
> 
> Maybe at some later stage when the stub code stabilises it could become
> part of the kernel build. But this is not a step to take lightly, one
> would have to convince the kernel team to accept it and then changes are
> more hassle to make as it's tied to the kernel release cycle.

Agreed.  
 
> >3) We can teach the kernel another bootloader && kernel independent
> >   protocol for passing command line information.  And have etherboot
> >   use that.
> 
> Etherboot could parse the DHCP reply itself and modify the command line,
> but I not keen on the idea of a significant amount of code in Etherboot
> that knows about the OS image format. 

I wasn't even thinking that.  I have some fairly generic code in
LinuxBIOS that says here is a command line.  Image make of it what you
will.  This is something that could be done in the generic ELF
support.   I preserve all registers at kernel entry so finding
something like this would be straight forward.

A command line is a generally useful concept so treating it specially
has some merit.
 
> It would put more pressure on the
> footprint, and would be wasted space when Etherboot is used to load
> other images.  Saving the space with conditional compilation might give
> rise to problem reports from users who had not configured it in. At
> least with the current config, both tagged and Elf are supported by
> default.  And it would be hard to make changes, once the Etherboot code
> has gone into ROMs. At least with mkelf-linux you can still tweak things
> later.

I totally agree that there is a use for a mkelf-linux that tweaks
things and implements policy.  With my changes this just becomes
easier.  Especially with the 32bit kernel enttry point, and the work
to find the lowest possible ramdisk address.  So the ramdisk will
not need to be relocated at runtime.

If you can take BIOS calls out of the picture things should get a
little easier :)

Eric