Johnathan Stone's address removed by request.

That doesn't mean that I'm not going to respond to his posting that
accompanied the request, since he made it in a public forum.  I do
not let "parting shots" slide.


> >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....

The point is to enable people who *do* "want to do such a thing";
if you don't, then your opinion on the matter is not requested,
only your opinion on implementation details (assuming you are a
competent coder).


> 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.

What are the benefits to running NetBSD instead of the native kernel,
if all the NetBSD kernel does is replace the native kernel without
any additional added value?  What's the point, is it just so you can
say "hey, I'm running NetBSD"?


> 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.

I have a working set of agregators.  I don't yet have a segment
attributed kernel, thought it should be possible to do something
similar to the "/fs/..." with the existing BSD install FS, which
is MFS based.

If we want proof of concept, USL and Sun have had this for four years.


> 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.

This is not true.  The bootblocks are to get a minimal kernel in;
the issue in question is that what constitutes a minimal kernel
varies based on what devices are or aren't "boot critical" devices.

This dovetails nicely into using VM86() in i386 to implement fallback
drivers that can work on any hardware installed on the machine.  For
Mac's this means ROM calls, for PPC's, this means PPCBug or Open Firmware,
for non-PPC Motorola systems, this means Bug calls, for Sun's this
means monitor calls, etc..  You load the hardware specific drivers
after you are up, including auxillary FS drivers.

But this is not required to make the concepts useful in the first
place.  I also admit that the concepts are only useful in terms of
blocking the fewest avenues of future expansion and exploration...
which was, after all, the intent.


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

Done.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.