FILO 0.4 [PMX:#]

[Eric W. Biederman]

ron minnich <rminnich at lanl.gov> writes:

> RE the bigger issue of compiling things direct into linuxbios. 
> 
> I've been thinking for some time of an experiment, namely turning this 
> whole business inside-out. Think of it this way: there is a runtime 
> startup for every program your write, called in old times crt0 (which is 
> why I used that name for LinuxBIOS). But from your point of view, your 
> program is not crt0, it's main(). 
> 
> So looking from the point of view of the compiler and library writers, who 
> know nothing of your program when they write the compilers and libraries, 
> the world is libc.a and crt0. You don't care about that, and from your 
> point of view, the world is your program. You use the compiler to get your 
> startup code and some library calls. 
> 
> This leads to a natural question: what if we think of linuxbios as
> something to be linked into a boot loader such as openbios, filo, 9load,
> or even a special linux kernel? In other words, invert our view of the
> world: we don't compile a boot loader as part of building linuxbios; we
> compile linuxbios into a bootloader. Linuxbios provides startup (analogous
> to crt0) and some library functions the boot loader needs (print* support,
> pci enumeration, etc) but the really important bit is the boot loader.
> 
> In this view, linuxbios is a library that you link your bootloader with to
> build a bios. This really changes things around a bit. It also removes 
> some nasty problems, as the bootloader no longer has to supply (e.g.) its 
> own PCI enumeration code, and can use the linuxbios PCI enumeration code, 
> which can help boot loaders avoid bugs in chips (consider the VT8601 and 
> the PCI bugs it used to have). 

The amount of code we are talking about there is about a 1000 lines 
(at least on x86), and can easily be shared by cut and paste.  I would
be surprised if PPC and other architectures were worse, but they may be.

As for avoiding bugs, the solution is to dump our device tree via the
LinuxBIOS table.  That is on the TODO list.  It has not been a big
enough problem for anyone to care about implementing it yet.

> This view is sort of halfway from old bios ideas (INT xy) and current
> ideas (the payload doesn't know linuxbios exists). It's a huge change --
> maybe a very bad idea, as it means that now LinuxBIOS provides an API,
> which we never intended it to do. I have no idea if it even makes sense --
> just wondering.

Yes this is how you implement a bad imitation of an OS.

First you start adding functions that the core LinuxBIOS code cares
nothing about so they are poorly maintained.

Then you turn into a shared library so multiple programs running
on the system can call you.

Then you implement support for binary plugin options roms.

You have to write multiple versions of your code for: 8, 16, 32, 64,
and 128 bit processor modes.  And they have to all cooperate nicely.

Basically you do what everyone has always done before and resulted
in a big maintenance nightmare.  I refuse to even consider maintaining
that.

I am really only interested only interested in supporting free-standing
programs.
 
> Back to our irregularly scheduled arguments :-)

Eric