On Wed, Mar 10, 2004 at 02:30:15PM -0500, Matthew Orgass wrote:
> On 2004-03-10 tlaronde@polynum.com wrote:
> 
> > On admin demand or on reboot time, this buffer could be saved as an
> > additional ELF section (say `.config') to the kernel, this section
> > being used to compile a custom kernel, and
> > being parsed by autoconf at boot time to enable/disable features.
> 
>   This isn't necessary, as you can write the kernel data structures
> directly in the kernel file.
> 
>   Separating out the probe functions would need changes to autoconf as
> well as every driver.

That's the crux of the implementation problem. In theory, you may want
to be able to identify the devices whether or not you are actually able
or willing to drive them. Since, as far as I understand (from the red 
daemon book), the probe functions are in the drivers and the action is
"probe and if present attach", the ability to extract just the probe
functions will depend on the organization of the code.

The alternative option being loading every driver (dynamically) and
freeing it just to discover. That's a bit heavy...

> 
>   I have at times considered the idea of a separate "priviledged userland
> domain" which would be able to affect the standard execution environment
> but would have its own separate root, init, and priviledge level and would
> not be signalable from the standard execution environment.  This would
> also make it possible to do things like userland disklable management (via
> slices), the desired parts of which could be placed in a memory disk for
> finding the root, but could also (if desired and with additonal memory
> disk code to do so) be freed once the system is up by using on disk
> versions.  This could result in some kernel memory use reduction once
> booted while increasing boot options.  It would, however, be a major
> change.

If I understand correctly, this could be partly "implemented" with the
scheme of my "virtual kernel root fs", the "priviledged userland domain"
being an userland access for the "kernel root user": ability to launch
some programs at config time, and to free the stuff when going to
classical userland state, mounting another rootfs on the virtual kernel
rootfs. 

And then we are back to a kernel based bootloader with some
"specialized" userland stuff. That's perhaps unavoidable and will have
some benefits for embedded applications. YMMV.

IIRC, the Linux based OSes since kernel 2.4 are using extensively the 
memory disk to provide bootstrapping time flexibility (in classical 
userland environment) with the ability to `pivot_root()' that is to 
replace the rootfs at running time (but it is a bit acrobatics). And
this is not what you're describing.

Logically, since the kernel threads are special processes, it would make
sense to give them as root what I call the "virtual kernel root" 
since you will be able to umount any external rootfs without much ado
all the kernel threads references being in the kernel by itself.

I think it's time to follow His Wonderland's Majesty's advice "Begin 
at the beginning," the King said very gravely, "and go on till you 
come to the end: then stop", i.e. time to look at the code to see what 
is achievable and what is desirable ;)
-- 
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C