Followup to: <200006141949.VAA09667@lrcsun15.epfl.ch>
By author: Werner Almesberger <almesber@lrc.epfl.ch>
In newsgroup: linux.dev.kernel
>
> James H. Cloos Jr. wrote:
> > Cool. But so would be getting rid of bzImage in the general case.
> > Using a two-stage loader (unless it can be done in 1) to boot a
> > vmlinux.gz file from a filesystem would be way cool.
>
> There are a few boot loaders around that understand certain file
> systems (GRUB is probably the most popular one), but putting such
> functionality into the boot loader doesn't scale well. (See below.)
>
> A much better approach is to, use the Linux kernel as your second stage.
> Advantages:
> - boot loaders to load that one already exist (although they're
> over-featured it this is all they're asked to do)
> - you can handle all kinds of exotic things very easily, e.g.
> ReiserFS, ext3, XFS, JFS, LVM, RAID, network boot (TFTP, HTTP,
> FTP, NFS, HTTPS, you name it), etc.
>
> There's already some fairly advanced work in this direction (bootimg,
> Lobos, Monte).
>
> 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.
I have so far worked mostly on the (a) approach in working on
"Genesis". Unfortunately, the Linux VFS is very poorly separated out
from the rest of the kernel, which means this has ended up being more
difficult than I expected -- and I didn't expect it to be easy.
I'm seriously starting to think (b) would have been a better
approach; the BIOS INT13h would then be a block device in the
stripped-down Linux kernel. The big disadvantage with (b) is that the
entire Linux kernel is such severe overkill.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt- 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