Re: Grub: Does it allow for modularized kernel fs
Sorry I just discovered, that this thread isn't relayed (?!?) to the usenet
newsgroup, so I wasn't aware of theses messages. I'm replying in just
one
message.
> > > > Does anyone know if the fs in Grub allows the kernel to load his
> > > > necessary fs as modules? I.e. if Grub contains a an ext2 fs, can the
> > [...]
> > > Both the kernel and grub don't care about each other, in fact, both
> > > don't no a thing about the other end [1]. So, yes, you still need
> > > compiled-in kernel support for both the root fs and the disk type this
> > > fs is on. And, if you want to use other filesystems or disk types after
> > > booting the kernel, you either need kernel support compiled-in or as a
> > > module.
> > >
> > Bad luck, so it never will be possible to have a fully modularized kernel.
>
> Sure you can ... use an initrd.
I quote:
"initrd is mainly designed to allow system startup to occur in two phases,
where the kernel comes up with a minimum set of compiled-in drivers, and
where additional modules are loaded from initrd"
I think initrd is not meant to be used as a helper for for a kernel without
built-in fs and drivers in general. It looks (IMHO) more like a hack in
cases where space requirement enforces it. But how about if the root-fs
of
initrd resides on the boot track on the disk instead loaded into ram disk?
The purpose of such an arrangement is not only to have a fully modularized
kernel, it's more that the kernel can access any volume without having the
necessary support already built-in. I envision a solution where the kernel
can access a volume containing an fs which wasn't known when the kernel was
compiled.
----------------------------------------------------------------------------
> Err, not so fast! I think HURD actually provides this, and grub has
> hooks to load a specific module set for the HURD. It won't use that
> module itself though.
>
Fine this could be the first real reason (for me) to switch to Hurd.
O. Wyss
Reply to: