答复: FILO 0.4 [PMX:#]

[YhLu]

Eric,

If the put the etherboot and filo in the ROM at the same time for fallback
mode,

Is it possible to make payload be selected by the elfboot? ( Controlled by
cmos layout or key) 

Or let the Etherboot load another elf in ROM instead of HD? ( in the boot
option add BOOT_ELF or BOOT_ZELF together with BOOT_NIC, BOOT_DISK,
BOOT_FLOPPY).

Regards

YH

-----邮件原件-----
发件人: Stefan Reinauer [mailto:stepan at openbios.org] 
发送时间: 2004年4月5日 5:47
收件人: Eric W. Biederman
抄送: Greg Watson; YhLu; 'SONE Takeshi'; linuxbios at clustermatic.org
主题: Re: FILO 0.4 [PMX:#]

* Eric W. Biederman <ebiederman at lnxi.com> [040405 05:02]:
> If we want to take a snapshot of the source tree of FILO or any other
> bootloader into the LinuxBIOS tree under util.  Build that part of the
> build and build a complete romimage that works.  I am fine
> with that.  It is even reasonable to make it so you can drop in
> external trees like etherboot and have everything build together
> nicely.
> 
> Actual linking things together instead of including them together
> is unacceptable.

What about the following:

Currently LinuxBIOS divides into 2 fundamental parts:

1) hardware initialization
2) getting and starting the payload

This second part consists of two parts, again:

i) elfloader
ii) payload

Note, this is only one possible design. Maybe, this design is bloated
for some application cases. 

Eric, you want to make a hard cut between what is LinuxBIOS and what is
not. This is generally a good idea, as it keeps the different
initialization steps distinct from reach other. What, if we add another
cut by dividing hardware initialization frin the payload-loader?

Instead of packing stuff like filo to util, we could do:

* create a directory loader which can hold all "loaders"
* move the elf loader with a Config.lb to a subdirectory in there
* create other directories for other "loaders" like filo.

If done right, filo can still be compiled as a payload, or built in if
the win in size is noticable. A target config file could probably choose 
which method to use, without overhead. Also, syncing with other trees,
like Takeshi's filo tree could be fairly easy, too.

I don't think we really have a conflict in direction here at all.
LinuxBIOS itself should be as small as possible, and the different parts
should be as independent as possible. But we also want to be a lot more
flexible than the existing solutions..

> In addition we have had way to many questions of what is the right
> policy for a bootloader to implement, on this list.  I refuse
> to couple that to the LinuxBIOS core.  And I don't want some stupid
> policy in there like FILO's that would require me to upgrade
> my firmware just to upgrade my OS.

Please explain, how is filo worse here than putting linux in flash?


Stefan