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