>It doesn't make a lot of difference, unless you decide to replace the
>agregation (generic) "mount" command with an FS specific "mount" command
>at boot time.  

I honestly still dont see why I'd ever want to do such a thing....


>But the ability to replace the "generic" (agregating) commands with
>an FS specific command at varios stages of the boot is valuable to
>replacing existing kernels on non-BS systems with your BSD kernel,
>and having things "just work".  It's an important factor if you
>ever want to pursue the "competitive upgrade" market with BSD kernels
>replacing the native kernels for the OS installed on the machine.

For the systems I contemplate replacing, I can drop in a NetBSD kernel
with a linked-in kernel module which implements the replaced OS's
native filesystem.  NetBSD already has an emul system that lets it run
the native OS's ``agregator'' [sic] and FS-specific mount utility.




How much of your ``we have'', ``we can'', and ``posit'' is actually
real code, and how much is viewgraph engineering?  It sounds rather
complicated. It seems a fair question to ask what the overhead is to
make all this work.

It smells to me like you're really foisting off so much work onto the
bootblocks that deal with this `kernel as an FS' model, that we might
as well start calling the *bootblocks* the kernel, and the rest of
your ``kernel'' is just a library of OS modules. I think that is going
to set off many peoples' bogosity meters for the whole idea.

Would you mind taking my address off any further replies, please?