"H. Peter Anvin" <hpa@zytor.com> writes:
> Followup to: <m1g0kycm0x.fsf@frodo.biederman.org>
> By author: ebiederm@xmission.com (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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 21:00:21 EST