Hmm, for now the only problem would be that file descriptors >255
are not accessible through /dev/fd - everything else should still work
fine. BTW, the current /proc/*/fd has the same limitation (fd == low
8 bits of inode number). And we are moving to a 32-bit dev_t...
> expanding the major/minor device numbers? Seems to me this would be
> additional motivation for both, and I don't see systems wanting >
> 65,568 open files (assuming that the minor number becomes 16 bits).
It's 65536 - should be enough for quite some time :-).
> The question is, what advantages does /dev/fd/* have over
> /proc/self/fd/* ?
One is that these are character devices and don't need to be tainted
(programs like ftpd won't let you read it, avoiding access to ftpd's
open files such as wtmp or /etc/shadow). /proc files look like regular
files even though they really aren't. Also, by opening /dev/fd/n you
get a dup() of the file descriptor - that was the case some time ago
(known as Plan9 semantics) but stopped working later. If it's the way
it works on other systems, we'd better follow that, just in case there
are programs which rely on the standard /dev/fd behaviour...
One disadvantage is that you can't open file descriptors from other
processes - but it's rarely needed, and can be a security problem
if not done right.
The problem still remains: it would be nice to be able to replace
most of the open() function (including get_empty_filp()) with
something driver-specific. But I guess that would require some
changes in the order how things are done - currently we call
get_empty_filp() before open_namei(). (Is this order important?)
> This is not a kernel issue at all. The proc fs can be mounted
> anywhere you like, including multiple places. (Try it :). The only
Yes, I know. That's why I said it's somewhat unrelated :). But it
also gives us a chance to reorganize our /proc and do some things
better without breaking existing programs. Once everyone is using
the new procfs, the old /proc mount point can be used for a SVR4-
like (not just Solaris - it seems that it's at least similar on
Digital Unix, which Linux/Alpha tries to be binary-compatible with)
/proc filesystem if/when that is implemented.
Marek