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

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

<ja...@Mc...> writes:

> Eric,
> 
> I see you've added the ability to add kernel command line
> args at compile time, and it looks like there will be a
> tool to update those command line args, but I can't really tell
> from your description if you've kept the ability to pass
> kernel command line args via dhcp options.
> 
> Over at LTSP, we really like the ability to set those
> args in dhcpd.conf.  That way, we can use the same kernel
> for all of the workstations, and the differences are all
> maintained in the dhcpd.conf file.

Which is a sensible thing to do.  In this case the kernel never has
directly understood etherboot, or a command line passed as dhcp
options I haven't added that capability.  I have not used the
capability to pass a command line via dhcp as the couple of times I
tried it a long time ago it didn't work.  And then I built up the
infrastructure to make assmebling a kernel, a command line, and a
ramdisk into a network bootable image easy.  

It should be just a couple of hours to code.  My goal has been to
lower the barrier to doing a lot of this. 

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.  

2) We can teach the kernel about etherboot specifically and let it
   pick the command line out the dhcp options etherboots passes.

3) We can teach the kernel another bootloader && kernel independent
   protocol for passing command line information.  And have etherboot
   use that.

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.

Eric