On 2004-03-10 tlaronde@polynum.com wrote:

> But your suggestion has driven me to this possible solution. Create a
> config buffer, a la message buffer, where two distinct kinds of strings
> are written:
>
> 1) Description of devices found
> 2) Actions: the classical enable/disable action that one may, at
> present, interactively enter when invoking boot -c
>
> 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.

> After some thoughts, I think that there may be at least one problem with
> this scheme: if the host using NFSroot starts a cpu and memory intensive
> user program, the code for the NFS client (userspace) will be swapped
> out. And if the initial programs in the MFS are no longer accessible, a
> beautiful panic will follow.

  NetBSD has an NFS client in the kernel, so even if you mount it from
userland it should remain accessable (unless you need a different client
for some reason).

  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.

Matthew Orgass
darkstar@city-net.com