Is /dev/fd redundant to /proc/self/fd ?

Is /dev/fd redundant to /proc/self/fd ?

Post by Richard L. Hamilt » Mon, 27 May 2002 19:18:21



Looking in /dev/fd, I see files corresponding to file descriptors
0 through 62, notwithstanding that only 0, 1, and 5 are actually
open.  But that behavior is not described in the fd(4) man page.

So is there any reason to have both /dev/fd and /proc/self/fd ?
Or to put it another way, is there anything that would break if
one removed the /dev/fd line from /etc/vfstab and replaced the
/dev/fd line with a symlink to /proc/self/fd ?

If not, why maintain both?

--

 
 
 

Is /dev/fd redundant to /proc/self/fd ?

Post by Casper H.S. Di » Mon, 27 May 2002 20:06:22



Quote:>Looking in /dev/fd, I see files corresponding to file descriptors
>0 through 62, notwithstanding that only 0, 1, and 5 are actually
>open.  But that behavior is not described in the fd(4) man page.

The size of /dev/fd is per-process but it's always fully populated.
(It's sized according to a process' fd table)

Quote:>So is there any reason to have both /dev/fd and /proc/self/fd ?
>Or to put it another way, is there anything that would break if
>one removed the /dev/fd line from /etc/vfstab and replaced the
>/dev/fd line with a symlink to /proc/self/fd ?

I'm not sure if a process can open all of its /proc/self/fds.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Is /dev/fd redundant to /proc/self/fd ?

Post by Chris Thomps » Tue, 28 May 2002 01:25:44




Quote:>Looking in /dev/fd, I see files corresponding to file descriptors
>0 through 62, notwithstanding that only 0, 1, and 5 are actually
>open.  But that behavior is not described in the fd(4) man page.

Not explicitly, but so what?

If you do a readdir() on /dev/fd then you see entries for all numbers
less that the current soft fd limit, e.g.

  $ (ulimit -n 12 ; ls -f /dev/fd)
  .   ..  0   1   2   3   4   5   6   7   8   9   10  11

This doesn't necessarily cover all currently open fd's. But you can
stat() any number inside /dev/fd and it will get you an answer:

  $ ulimit -n
  256
  $ ls -l /dev/fd/99999
  crw-rw-rw-   1 root     root     234,99999 May 26 17:03 /dev/fd/99999

An entirely nominal answer, because there is no device driver for this
character device. If you did a "mknod /some/device c 234 99999" then
/some/device would not behave like /dev/fd/99999.

The effect of opening an entry in /dev/fd (i.e. dup()ing the referenced
fd) is unrelated to the results of readdir() or stat(). Filing system
implementations can do things like that!

Quote:>So is there any reason to have both /dev/fd and /proc/self/fd ?

I think opening a file in /proc/self/fd is slightly different from the
dup()ing that /dev/fd does. You get an independent seek pointer, for
example.

Quote:>Or to put it another way, is there anything that would break if
>one removed the /dev/fd line from /etc/vfstab and replaced the
>/dev/fd line with a symlink to /proc/self/fd ?

Ugh! Anyone want to try the experiment?

Quote:>If not, why maintain both?

/dev/fd is much older, of course (in Solaris it goes back to 2.0 vs 2.6),
and it exists in more Unix flavours.

Chris Thompson
Email: cet1 [at] cam.ac.uk

 
 
 

Is /dev/fd redundant to /proc/self/fd ?

Post by Roger A. Faulkn » Wed, 29 May 2002 11:37:51




Quote:>Looking in /dev/fd, I see files corresponding to file descriptors
>0 through 62, notwithstanding that only 0, 1, and 5 are actually
>open.  But that behavior is not described in the fd(4) man page.

>So is there any reason to have both /dev/fd and /proc/self/fd ?
>Or to put it another way, is there anything that would break if
>one removed the /dev/fd line from /etc/vfstab and replaced the
>/dev/fd line with a symlink to /proc/self/fd ?

>If not, why maintain both?

The /dev/fd filesystem behaves quite differently from /proc/self/fd

Here is the relevant section from the fd(4) man page:

     If file descriptor n is open, these two system
     calls have the same effect:

     fd = open("/dev/fd/n", mode);
     fd = dup(n);

     On these files  creat(2) is equivalent to open, and mode  is
     ignored.  As  with   dup,  subsequent reads or writes on  fd
     fail unless the original file descriptor allows  the  opera-
     tions.

The essential semantic of files in /dev/fd is that opening one of
them is identical to dup()ing the corresponding file descriptor.

This is not the semantics of applying open() to a file in /proc/self/fd
Opening /proc/self/fd/n (if it succeeds at all; there are restrictions)
gives you a new file descriptor with its own seek offset.  It is not
a dup() of the old file descriptor.

I must admit that having a readdir() of /dev/fd return all possible
file descriptors rather than just the open file descriptors is
counter-intuitive and should be fixed.  It is not a high-priority
problem, though.

Roger Faulkner

 
 
 

Is /dev/fd redundant to /proc/self/fd ?

Post by Richard L. Hamilt » Thu, 30 May 2002 22:15:58






>>Looking in /dev/fd, I see files corresponding to file descriptors
>>0 through 62, notwithstanding that only 0, 1, and 5 are actually
>>open.  But that behavior is not described in the fd(4) man page.

>>So is there any reason to have both /dev/fd and /proc/self/fd ?
>>Or to put it another way, is there anything that would break if
>>one removed the /dev/fd line from /etc/vfstab and replaced the
>>/dev/fd line with a symlink to /proc/self/fd ?

>>If not, why maintain both?

> The /dev/fd filesystem behaves quite differently from /proc/self/fd

> Here is the relevant section from the fd(4) man page:

>      If file descriptor n is open, these two system
>      calls have the same effect:

>      fd = open("/dev/fd/n", mode);
>      fd = dup(n);

>      On these files  creat(2) is equivalent to open, and mode  is
>      ignored.  As  with   dup,  subsequent reads or writes on  fd
>      fail unless the original file descriptor allows  the  opera-
>      tions.

> The essential semantic of files in /dev/fd is that opening one of
> them is identical to dup()ing the corresponding file descriptor.

> This is not the semantics of applying open() to a file in /proc/self/fd
> Opening /proc/self/fd/n (if it succeeds at all; there are restrictions)
> gives you a new file descriptor with its own seek offset.  It is not
> a dup() of the old file descriptor.

> I must admit that having a readdir() of /dev/fd return all possible
> file descriptors rather than just the open file descriptors is
> counter-intuitive and should be fixed.  It is not a high-priority
> problem, though.

Ok, having an fd either pointing to the same or to a different file table
entry is a big difference; and I can see that both could be useful.
Indeed, I've always wanted a way to get a new fd from an existing one
but with a separate seek offset (would be handy for files with a
complex multi-part structure, if you wanted to be able to provide routines
that accessed them via regular file descriptors rather than by user-space
handles (like the elf routines provide) built on top of file descriptors.

I guess I'll have to look at just what the limitations are on opening
/proc/self/fd/NN files.

--