I think this is a great idea. I'll talk it over with Ron and Ollie this week and look at how it might be implemented.
Greg
On 05/04/2004, at 6:46 AM, Stefan Reinauer wrote:
* 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
