FILO 0.4 [PMX:#]

[ron minnich]

On 4 Apr 2004, Eric W. Biederman wrote:

> Personally the one I want is based on a real live kernel.  And if I can
> get some time that is what you will see.

Sure. That's where I started this project from almost 5 years ago. We only
have this plethora of bootloaders (etherboot, filo, 9load, etc.) because
our initial goals of a real live kernel proved techincally impossible --
flash was too small. 2.6 + bigger flashes might put us back where we were
4 years ago with the L440GX+ boards, with 1 MB flash and a 2.4.7 kernel
that easily fit in that space. We can hope so.

IIRC you and I had some discussion on this several years ago, on this
list, and you were firmly in the Etherboot camp, as you thought the small
fast Etherboot kernel had advantages over a full live Linux kernel. You
made some excellent arguments in favor of this idea. I argued that the
Etherboot approach was fundamentally flawed, and that in the end I wanted
a live kernel in there for booting. We agreed to disagree. So I'm glad to
have you back :-)

Just kidding. You and I both know the excellent Etherboot work you did was
a real accomplishment and definitely saved our collective necks.

But: you have to at some point consider what people are asking for, and we
do think about that as we get a lot of requests here not reflected to the
list.

Some ongoing requests: VGA that works in linuxbios, and a boot prompt that
can allow a user to type a pathname to a CD image and do an install. One
build, not two or three. And people want it in one package.  The
requirement with the current setup to build multiple binaries such as
Etherboot at present can't do this. Greg's test integrated FILO can. We
also need the emulator in linuxbios because that is the only practical way
to get to this demand. And it's got to be very very small. Some of the 
recent changes in V2 have been tough on the embedded folks, and that is of 
real concern to us. Please bear in mind that you folks at LNXI are not as 
affected by the embedded world as we are down here, and I have had a 
number of comments about V2 in that regard. 

Hence these trial changes. Plus, a simple fact: if you don't like them, 
don't enable them. Nobody's locking them in. We are making them available 
to those who can use them. The goal is flexibility. 

We've also had lots of people with issues with the ELF loader approach.  
Requiring an ELF target is requiring a policy as near as I can tell.  
Many people don't want to deal with mkelfImage, esp. as it has proven to
be non-portable in some cases (maybe this can be fixed, but if you
mkelfImage on a 64-bit K8, etherboot coughs and dies in the elf loader 
-- there are issues).

Also, re this: "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.  "
                                   
To most people, the distinction between "payload in flash" and "linuxbios 
in flash" is immaterial. In other words, these folks don't care about the 
seperation between LinuxBIOS and payload! they are much happier with an 
integrated one-step system that boots an OS. What they want is to be able 
to install from CD. Etherboot won't let them do this, and neither will an 
ELF loader. Integrated Filo gives people something they can use today, 
that will be easy to build. 

Finally, let's remember that the ultimate goal of a project such as
LinuxBIOS is utility, not beauty and beauty alone. Sometimes what some
people consider beautiful is sacrificed in order to support needs of
customers. Let's not go so far into concern for beauty that we forget that
lesson. I'm maxed out on 'beauty uber alles' on the Plan 9 list.

Anyway, before this conversation gets too hot, please everyone take a deep 
breath, remember your email etiquette, and don't forget we are all friends 
here. It's important to resolve these issues in an atmosphere of 
cordiality. 

ron