Ronald G Minnich <[EMAIL PROTECTED]> writes:
> On 14 Jun 2001, Eric W. Biederman wrote:
>
> > The more I think about it, I keep thinking we could use something
> > very small, and limited for the fail safe booting case. So you misflash
> > your linux kernel you still have a chance to recover.
>
> Should we consider linking in tiara as the "first level"? Then your
> options are "boot linux from flash" etc.
>
> I want to avoid writing our own operating system, which is what these
> bioses always turn into sooner or later. Look at Open Boot, SRM, etc.
>
> I also want to avoid what happened to the Sun bootstrap: at some point you
> built it by yanking in huge bits of kernel source. Almost but not quite a
> kernel.
>
> I actually considered putting TCL in there as the first level boot at one
> point ... but the system should always be able to boot with minimal fuss
> in the "common case" -- i.e. everything is working.
>
> A point solution that works on one chipset may well grow to very large
> size and complexity if ported to lots of chipsets. At the very least we'll
> be writing drivers for everything, redoing work already done in linux.
>
> I don't know, this is a tough call.
Agreed. But given how much is already in linuxBIOS already PCI
init etc. That should really be moved out, I think there is a good
argument for a fail safe booter. Tiara is already bigger and more
complicated than what I have in mind. A basic rule of thumb would
be that if your fail safe booter + linuxbios needs more than 64K
of flash it has gotten too big.
Mostly I want somewhere we can dump code that shouldn't be in
linuxBIOS proper but we keep writing anyway, and throwing
a very minimal hardware driver and calling it a fail safe
booter seems to make the picture complete.
The one possitive thing I have seen with etherboot, is that minimal
hardware drivers you write for a single project can be very simple,
reliable and small.
Everytime I have seen a project attempt to use drivers from another
source MILO, MACH, oskit. At best they succesfully import the
drivers ande get the benefit of the state of the art at that point
in time but they don't get shared maintenace, and after a while
things diverge. And they drivers are never updated. So I certainly
don't want to see any drivers we don't have the bandwidth to write and
maintain. With that said I think some very common hardware can be
supported.
At this point I won't get anything serious in this vain, except
thinking even started until mid July after I come back from vacation.
Eric
