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:[EMAIL PROTECTED] 发送时间: 2004年4月5日 5:47 收件人: Eric W. Biederman 抄送: Greg Watson; YhLu; 'SONE Takeshi'; [EMAIL PROTECTED] 主题: Re: FILO 0.4 [PMX:#] * Eric W. Biederman <[EMAIL PROTECTED]> [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 _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
