FILO 0.4 [PMX:#]

[Greg Watson]

Stefan,

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