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

[<ke...@us...>]

>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. 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.

Users who don't need to extract options from DHCP or append initrds
could just use the kernel Elfs directly.

>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.

>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. 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 don't know which is the best route to go.  All I know for certain
>is that.
>A)  I am doing the heavy lifting to so the kernel supports things
>    like this.   A few more tweaks and I can place a ramdisk at a fixed
>    address in ram.
>
>B)  It really makes sense to generate an ELF image that works
>    in 90% of the circumstances.  Even if it isn't optimal.
>
>My hunch is that the optimal method is to build a smart dhcp/tftp
>server that builds whatever file your kernel needs on the fly.

This could be yet another technique in the armory and could be used in
quite innovative ways not limited to booting OSes. Anybody want to hack
an existing tftpd? E.g.  tftp-hpa or atftp. My idea is a tftpd that can
accept a filename which is actually a spec file for putting an image
together. Sort of like dynamic web pages.