"H. Peter Anvin" wrote:
> Followup to: <200006141949.VAA09667@lrcsun15.epfl.ch>
> By author: Werner Almesberger <almesber@lrc.epfl.ch>
> > For space-constrained cases (e.g. embedded systems), the existing
> > comparably lean interfaces between boot loader and kernel should of
> > course be preserved.
> There is a major -- I would say, fatal -- problem with that: the Linux
> kernel doesn't allow access to the device drivers in the bootstrap ROM
> (i.e. the BIOS.) This becomes particularly problematic if you want --
> and I argue you *do* want -- the boot loader to assemble a
> kernel/initrd to match your system hardware configuration.
>
> The obvious solution is to construct a boot loader such that it can
> use Linux kernel filesystems. There are two ways to do this, and I am
> yet to be certain which way is really the better.
>
> a) Built a boot loader with a VFS that is similar enough to the Linux
> kernel internals that it is easy enough to port drivers.
>
> b) Strip down the Linux kernel so that it can run on top of the BIOS.
> This means all interrupts are handled by passing them to the BIOS;
> at that point, the Linux kernel can execute BIOS calls by dropping
> down to real mode.
c) Build a better BIOS.
Though I think it would be nice to be able to break the kernel down,
much further than is currently possible, to make feasible
linux-booting-linux or really small, embedded linux. A lot of stuff is
linked into the core kernel image by default that is simply not needed
when running a "lean lean" kernel.
Jeff
-- Jeff Garzik | Liberty is always dangerous, but Building 1024 | it is the safest thing we have. MandrakeSoft, Inc. | -- Harry Emerson Fosdick- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:33 EST