Subject: Re: Firmware upload - generalize it?
To: None <tech-kern@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 06/01/2005 02:24:40
> As I've asked before, how many namespaces do we really need to have
> in our system (beyond system calls and filesystem names, I suppose)
> and why, exactly, is it a good thing for those namespaces to
> proliferate?

I think most of the ones we need, we have to keep for compatability,
either with historical practice or with other OSes we want to be
binary-compatible with.

But I can think of quite a number of namespaces, some of them naming
the same, or nearly the same, things.  I'm restricting myself to names
that cross the user/kernel boundary, or there would be a lot more.  In
cases I expect doubt, I name some calls that use them.

I must say, I'm astonished at how many different namespaces I find when
I start looking for them.

- system call numbers (you mentioned this one)
- filesystem paths (you mentioned this one)
- network interface names (mentioned upthread)
- user IDs
- user names (setlogin, getlogin)
- group IDs (setgroups, getgroups)
- process IDs, which also get used as
  - process group IDs (setpgid)
  - session IDs (getsid)
- sysctl nodes
- SysV shared memory segment IDs
- SysV semaphore IDs
- SysV message queue IDs
- file descriptors
- AF_LOCAL socket addresses[%]
- AF_INET socket addresses
- AF_INET6 socket addresses
- socket addresses in other address families[$]
- <address,size> pairs naming memory segments (mmap, mprotect, etc)
- hostnames (sethostname/gethostname)
- device <major,minor> numbers
- NFS file handles (getfh, fhopen)

There are a whole lot more special-purpose small-integer namespaces,
which I'm not sure we should count:

- sysarch requests
- pathconf value IDs (eg _PC_NAME_MAX)
- interval timer IDs (eg ITIMER_REAL)
- resource limit IDs (eg RLIMIT_CORE)
- setrlimit ID space IDs (eg PRIO_PROCESS)
- fcntl requests (eg F_GETFD)
- ioctl operations (eg FIONREAD)
- socket address/protocol families (eg AF_INET, PF_INET)
- socket types (eg SOCK_STREAM)
- socket option levels (eg SOL_SOCKET)
- socket options (eg SO_LINGER)

Getting even farther into the maybe-not zone, there are the O_* flags
to open() and, for most of them, fcntl(); memory protection bits; mmap
sharing type values; lseek whence values; reboot() flags; poll() event
bits; ktrace what-to-trace bits; and probably others I've missed.

[%] That these are overloaded onto the filesystem namespace has always
    seemed like a gross implementation kludge to me.  Of course, it's
    one it's *far* too late to fix....

[$] The only other networking protocols I've worked with to any
    significant extent are Chaosnet and DECnet, and I don't think we
    support either one.  There are doubtless some we support that I've
    never worked with, though.

Yes, they have proliferated.  I'm not sure how many of those we *could*
do away with, and many of them (especially the small-integer ones like
SOCK_STREAM) I'm fairly sure we don't want to get rid of.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B