[ On Saturday, March 25, 2000 at 13:55:57 (-0500), der Mouse wrote: ]
> Subject: Re: sysctl(2) and/or /kern for system variable manipulation
>
> > Indeed the concept of having so many namespaces in BSD is highly
> > questionable.  libkvm, sysctl, et al should all be moved to the
> > filesystem namespace.
> 
> "Should"?  Why?  What's wrong with having many namespaces?

Many namespaces mean many different ways of managing, accessing,
controlling, etc. the objects being accessed.  This means added
complexity with the potential for confusion and unsafe assumptions being
made by users; and sometimes additional bloat too.

The developers of Research UNIX and Plan 9 have made solid arguments
that I won't further repeat here in favour of using the filesystem
namespace consistently for all system objects.  Indeed they even went so
far as to show the advantages of using filesystem semantics for
accessing things like network services.  Their arguments are elegant and
simple and the result is I think simpler and certainly less complex.

>   Separate
> namespaces have many good properties - for example, a chrooted program
> can still manipulate AF_INET sockets normally.  (This can be looked
> upon as good or bad, depending on your inclination.)

Virtual filesystems have that property too.  You should be able to mount
the virtual filesystem multiple places where it makes sense to allow
this, such as in "mount -r -t sysctl /chroothome/sysctl".  Note the
proposed use of '-r' in this pseudo-example to ensure this instance of
the sysctl tree is read-only.  Of course some objects will still only be
readable by root no matter who owned the underlying mount- point
directory.

Note also that given support for changing the permissions on virtual
filesystem objects the same tools used for protecting files can also be
used to protect objects visible through a virtual filesystem.  I can
even see how a slightly modified unionfs could be used to provide safe
and persistent storage for permissions and ownership information for at
least some types of virtual filesystems.

I personally can't think of any good properties of separate namespaces
for system objects that are not also properties of unified filesystem
namespaces if they've been implemented with these goals in mind.

> Personally, the main reason I want ps -M ... -N ... instead of a
> separate crash-type program is that I can be sure it's the same ps,
> supporting all the same options in exactly the same way, with all the
> same output formats, etc, etc.

Yes there are certainly advantages to having such a common foundation
toolset that works on running kernels as well as crash dumps.

> It occurs to me that it might well be sufficient to have a tool that
> presents a kernfs-style mountable interface, but instead of being
> driven off a live kernel it's driven off netbsd.0.core and netbsd.0
> files.  It seems this might end up being more work than the other way,
> but it seems to me it should be at least considered.

I was thinking of that too.  While I don't see any hard obstacles in
building a tool that could offer something like /proc and /kern from a
crash dump, I do agree that it would probably be more work than simply
developing a unified crash analysis toolset.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>