"H. Peter Anvin" <[EMAIL PROTECTED]> writes:

> Followup to:  <[EMAIL PROTECTED]>
> By author:    [EMAIL PROTECTED] (Eric W. Biederman)
> In newsgroup: linux.dev.kernel
> > > > 
> > > > The interface is designed to be simple and inflexible yet very
> > > > powerful.  To that end the code just takes an elf binary, and a
> > > > command line.  The started image also takes an environment generated
> > > > by the kernel of all of the unprobeable hardware details.
> > > 
> > > Isn't this what milo does on alpha?
> > 
> > Similar milo uses kernel drivers in it's own framework.  
> > This has proved to be a major maintenance problem.  Milo is nearly
> > a kernel fork.  
> > 
> > The design is for the long term to get this incorporated into the
> > kernel, and even if not a small kernel patch should be easier to
> > maintain that a harness for calling kernel drivers.
> > 
> 
> I'm working on something similiar in "Genesis".  It pretty much is (or
> rather, will be) a kernel *port*, not a fork; the port is such that it
> can run on top of a simple BIOS extender and thus access the boot
> media.

Hmm.  You must mean similiar to milo.

Have fun.  With linuxBIOS I'm working exactly the other way.  Killing
off the BIOS.  And letting the initial firmware be just a boot loader.
The reduction is complexity should make it more reliable.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to