Messages in this thread |  | | From | Marek Michalkiewicz <> | Subject | /dev/fd (was Re: setuid scripts ...) | Date | Tue, 1 Oct 1996 20:25:17 +0200 (MET DST) |
| |
Larry 'Daffy' Daffner: > Albert Cahalan writes: > -> From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl> > -> > > -> > Or maybe we should start working on a "real" /dev/fd filesystem as > -> > found on Solaris (possibly other systems too, but I can't check right > -> ... > -> > One nice thing about these files is that they are really character > -> > devices (minor number == fd number), and so they don't need to be > -> > -> Then fd numbers are limited by the biggest minor number. > > Well, the largest fd number and the largest major mumber are the same > in the default configuration (Although you'd seriously PO the people > that bump the maxfd up to 1024). Also, wasn't there talk about
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
|  |