Subject: Re: sysctl(2) and/or /kern for system variable manipulation
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 03/26/2000 02:11:25
>> "Should"? Why? What's wrong with having many namespaces?
> Many namespaces mean many different ways of managing, accessing,
> controlling, etc. the objects being accessed.
Yes - one way per namespace. I'm not convinced this is necessarily a
bad thing.
> This means added complexity with the potential for confusion and
> unsafe assumptions being made by users; and sometimes additional
> bloat too.
Sometimes, especially when there exist objects that appear in multiple
namespaces.
But them excepted, I don't see why each object type shouldn't have a
namespace suited to its nature. The file paradigm is remarkably
robust, but that's largely because of the unstructured ioctl() escape
hatch, secondarily because people accept pseudo-filesystems that
severely break many ordinary filesystem operations. The filesystem
simply is not a good fit to many abstractions. Look at all the things
you can't do with procfs, for example: both things you can do with
processes but not procfs "files", and things you can do with normal
files that you can't do with procfs "files". (Simple examples: there's
no procfs analog to fork() - the closest would be cp, and that's not a
good fit - nor is there a process analog to mkdir().)
> 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.
It's an interesting paradigm, but as I indicated above, is has the
problem that it ends up twisting everything into the filesystem mold.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B