ron minnich <rminnich(a)lanl.gov> writes:
RE the bigger issue of compiling things direct into
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 --
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
I am really only interested only interested in supporting free-standing
Back to our irregularly scheduled arguments :-)