Subject: Re: sysctl(2) and/or /kern for system variable manipulation
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
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
> 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
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.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B