[Please CC me on possible replies. Thanks.]
As I was working with/on GRUB, and playing with initrd, pivot_root and
so on, numerous drawbacks seemed to lead to one possible theorical
solution, that could be applied to others "kernels" too ;)
If this has been already discussed, sorry and please give me some
pointers to the previous threads.
Short story.
GRUB, as a bootloader, can access data in block list, or can use file
system to access given files. Before selecting a "root" device, the GRUB
can be used via a shell interface.
Since more and more informations are retrieved from the machine, and can
be of some use for the OS loaded, a logical solution to publish these
dynamically acquired data is a virtual fs (a kind of /proc).
Since we try to detect the possible devices from which one can try to
load a kernel or a rootfs from, a kind of /dev to publish the present
devices is a logical solution too.
But, since the "core" GRUB "kernel" is meant to allow the bootstrapping
of major OSes, one can see the builtin functions to carry this out as
the major services, that could be accessed via a script language and so,
publishing them under a, say, `/kbin' (pseudo fs allowing the use of
kernel internals via scripting) could be a solution, while the "user
space" functions could be put out of GRUB kernel, supplementary
resources being mounted at need/will.
The key point is in fact that there is the idea of a virtual kernel
root, with some pseudo fs already set:
/
|
--/dev
|
--/kbin
|
--/proc
The "kernel" can be used via an interface that could be, for example, a
simple interface for debugging purpose, or a simple interface to change
the boot parameters.
Supplementary resources can be mounted on the kernel root (what is
called "root fs") with the difference that the kernel root virtual fs
stays always _on top_ : non kernel root fs don't mask the only root (the
kernel one), they just add resources to the root directory.
The advantages?
There is no more root problem for kernel threads, since
kernel threads run with the reference of the inchanged kernel root, the
common "root fs" being simply mounted or unmounted. No more "sliding
carpet" problem.
One can test or question the kernel via a simple interface for debugging
purposes. Not mounting supplementary resources doesn't create a panic,
but leave a bare bones kernel, giving for example the choice to the user
to give boot parameters.
The /dev (this is already the case with devfs) doesn't prevent from
mounting the "root" ro (for example when syslog tries to access a device
file created at run time).
Has an equivalent scheme being already discussed?
Cheers,
--
Thierry Laronde (Alceste) <[email protected]>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
<...>
> The key point is in fact that there is the idea of a virtual kernel
> root, with some pseudo fs already set:
>
> /
> |
> --/dev
> |
> --/kbin
> |
> --/proc
>
> The "kernel" can be used via an interface that could be, for example, a
> simple interface for debugging purpose, or a simple interface to change
> the boot parameters.
>
> Supplementary resources can be mounted on the kernel root (what is
> called "root fs") with the difference that the kernel root virtual fs
> stays always _on top_ : non kernel root fs don't mask the only root (the
> kernel one), they just add resources to the root directory.
>
> The advantages?
>
> There is no more root problem for kernel threads, since
> kernel threads run with the reference of the inchanged kernel root, the
> common "root fs" being simply mounted or unmounted. No more "sliding
> carpet" problem.
>
> One can test or question the kernel via a simple interface for debugging
> purposes. Not mounting supplementary resources doesn't create a panic,
> but leave a bare bones kernel, giving for example the choice to the user
> to give boot parameters.
>
> The /dev (this is already the case with devfs) doesn't prevent from
> mounting the "root" ro (for example when syslog tries to access a device
> file created at run time).
>
> Has an equivalent scheme being already discussed?
On linux/fs/namespace.c there is following comment: (from linux 2.4.12)
/*
* Absolutely minimal fake fs - only empty root directory and nothing else.
* In 2.5 we'll use ramfs or tmpfs, but for now it's all we need - just
* something to go with root vfsmount.
*/
<...>
static DECLARE_FSTYPE(root_fs_type, "rootfs", rootfs_read_super, FS_NOMOUNT);
But I do not think that that comment refers to equivalent scheme
than what you are proposing.
--
/"\ | Kari
\ / ASCII Ribbon Campaign | Hurtta
X Against HTML Mail |
/ \ |
On Sun, Oct 28, 2001 at 10:25:27AM +0200, Kari Hurtta wrote:
> >
> > Has an equivalent scheme being already discussed?
>
> On linux/fs/namespace.c there is following comment: (from linux 2.4.12)
>
> /*
> * Absolutely minimal fake fs - only empty root directory and nothing else.
> * In 2.5 we'll use ramfs or tmpfs, but for now it's all we need - just
> * something to go with root vfsmount.
> */
> <...>
> static DECLARE_FSTYPE(root_fs_type, "rootfs", rootfs_read_super, FS_NOMOUNT);
>
>
> But I do not think that that comment refers to equivalent scheme
> than what you are proposing.
Thanks for the tip. For the major part (don't speaking about /kbin or
something like that), I think the change would be more a way to see the
stuff than a lot of coding changes. In this case, having always and a
sole kernel root, will allow to mount all sort of fs (virtual or not),
and to allow kernel threads to refere to this unchanged root.
Cheers,
--
Thierry Laronde (Alceste) <[email protected]>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C