Re: GRUB shell consistency with Filesystem

[Thierry Laronde]

On Fri, Nov 09, 2001 at 10:46:45AM -0800, address@hidden wrote:
> 
> I looked at this call a bit, and it strikes me that supporting this
> is the Wrong Thing for 2 reasons:
> 
>   1) Having filesystem-specific hacks is kind of a mess.  Keeping the
>      code generic makes it MUCH more likely to work correctly and be
>      maintainable.
> 
>   2) The right way to fix this is to generalize the blockmap feature
>      to make it support partial blocks.  Other filesystems will likely
>      do this in the future, so it's better that we just bite the bullet.
> 
> Any comments on #2?
> 
> 
> In fact, I think both LILO and ReserFS (and arguably Linux in general)
> have gone the wrong way with their blockmap/unpack code/ioctls.
> 
> The Right Way to do this would be to make a program called "mkbootloader"
> or something that will take a filename and do 2 things with it:  produce
> a blockmap in a well-known format, and communicate via a generic ioctl
> (NOT a filesystem-specific one) that it needs to be on hardware block
> boundaries and be in a fixed location.
> 
> GRUB should use then this program and take the blocklist as input to set
> up it's installer.

Well, while playing with the GRUB and facing some issues with Linux, I
have thought about something that tallies, at least partly, these
issues.

Considering GRUB as a minimal kernel (to avoid the use of "micro" ;),
and aiming to reduce the size of this core ukernel, one can split the
utilities in two categories : the ones that belongs to
what_grub_is_supposed_to_do (bootstrap i.e. incremental start of a
machine) --- that can be considered as GRUB's system calls ---, and user
space utilities (utilities aimed to give the user a more easy to use
system).

To be able to expand, without recompiling the core kernel, the
utilities, we should be able to provide a way for the GRUB to access
supplementary resources (the classical root fs), with the chicken and
egg problem: how access resources, including fs drivers, if one needs
already the driver to access the resources. The problem here is
that with the increasing number of fs, to support all and the more
exotic ones will be more and more a PITA and, if one wants to have a
minimal core GRUB, recompilation (for example for distributions) will be
needed to include the driver to access the root fs.

But there is an alternative.

Linux, for example, panics if it can't access a root fs. Is it
mandatory? The answer is definitively: no, if one considers that a
kernel could provide a kernel's root pseudo fs, on which all "external"
fs are to be mounted. A kernel, left alone, will provide --- as GRUB
does --- a minimal interface allowing to talk to the kernel, the
kernel's pseudo root being always here --- one can note that for Linux,
for example, this will solve the problem of the sliding carpet when one
tries to pivot_root: kernel threads have to be related to the kernel's
root, not to external resources ; so changing the (external) root fs is
just umounting and mounting. All supplementary resources are mounted on
this kernel's root.

For GRUB, in the spirit, this is already what is provided. GRUB displays
the prompt that is a way to use the kernel's internals --- setup,
kernel, boot and so on. In the future, with a scripting language, the
system calls could be provided as pseudo files in the pseudo kernel's
root fs (i.e. /kbin/setup, /kbin/boot, ...).
We could then choose one and only one driver for supplementary resources
to allow GRUB to extand its abilities by accessing supplementary
resources (drivers in fact).

We could put all of this "fs" in a single file, with a well-known format
describing the list of blocks (relying for that on the OS and its
drivers), and the name, rights and addresses of the files within this file 
(a kind of extended tar fs). At installation time, stage1 has to know where 
to find stage2, and stage2 where to find the first block of its supplementary
resources (if there are none, it defaults to the core interface). When
GRUB tries to access a fs, it searches in its resources to find the
correct driver. If there are none, GRUB can still be installed on an
unsupported fs since everything can be put in "its" rootfs.

Yes, if we turn back to blocklist, a modification in the resources
imposes a reinstall that will be like the lilo installation. But, on
supported fs, this will not change anything (one can still put menu.lst
outside of the resources). And, for one, I don't think that to have the
possibility to avoid to rerun the bootloader initialization after
changing the kernel is that important.

Hum... Is at least something clear? ;)
-- 
Thierry Laronde (Alceste) <address@hidden>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C