6 ms·

Hopefully this isn't too hard of a rant, but file descriptors are... neither files nor descriptors. They literally don't "describe" anything about anything, and

Hopefully this isn't too hard of a rant, but file descriptors are... neither files nor descriptors. They literally don't "describe" anything about anything, and whatever they refer to doesn't need to be a file either. They're literally the exact opposite - 100% opaque integers, as opaque as anything in a program could possibly be, that could refer to pretty much any kernel object. Why they were ever called file descriptors in the first place (esp. given the one thing they lack is any description), and why they couldn't just start being called "handles" (like on Windows) or "object IDs" or something else that at least makes some modicum of sense, is beyond me.

akira2501 3y ago
They describe the state of a stream. Which are flags and a current offset at a minimum. On linux you can examine /proc/<pid>/fdinfo/<fd> to see what it 'describes' precisely.
- dataflow 3y ago
  The file descriptor doesn't describe anything. It's like your social security number, it's merely a unique identifier for something else. Does your SSN describe you as a human? What do I know about you as a human after I hear your SSN? Absolutely nothing.
  - akira2501 3y ago
    > What do I know about you as a human after I hear your SSN You know what part of the country I was born in, and using that, you can guess my age range. The interface is an opaque number, the implementation describes state, some of which is guaranteed to be present, one of which you can access using lseek(), which is a system call. In this case the state is even completely deterministic.
    - epcoa 3y ago
      > The interface is an opaque number While opaque for a subset of the API, it's not fully opaque since certain assumptions are made by the client based on their value: they are guaranteed to be reused and minimal. What this means is I can do close(0); open(...) to redirect stdin. > the implementation describes state, some of which is guaranteed to be present, one of which you can access using lseek() >> Which are flags and a current offset at a minimum. Uhh... no. Try that with pipes, sockets, FIFOs or any of the myriad other file types, eventfds, signalfds, kqueue, etc there are. Most open fds on a data center server likely don't meet your criteria. Even POSIX disagrees for the concept you are trying to convey cf "file description". https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
      - akira2501 3y ago
        > Even POSIX disagrees for the concept you are trying to convey cf "file description" You should have kept reading: 3.258 Open File Description A record of how a process or group of processes is accessing a file. Each file descriptor refers to exactly one open file description, but an open file description can be referred to by more than one file descriptor. The file offset, file status, and file access modes are attributes of an open file description.
        epcoa 3y ago
        "The file offset, file status, and file access modes are attributes of an open file description" That says file description there buddy, not descriptor. The two are defined separately, that is all. The single integer does not describe state in the way those terms are typically used; we have clearer vocabulary: refers, points to, etc that's fine. But it is a distinction with a difference. (They're not even unique). Edit: yeah, it says refers, not describes.
        akira2501 3y ago
        And, read more carefully, emphasis added: "Each file descriptor refers to exactly one open file description" Different integers are always unique. It's the file description that isn't: "but an open file description can be referred to by more than one file descriptor." You're attempting to make a huge distinction between interface and implementation. I can't rightly determine why.
    - tialaramex 3y ago
      Actually in the modern era SSNs are assigned randomly. Anybody born before about 2011 who hasn't needed a re-assignment will indeed have SSNs which in some sense contain information, but after this date they're just arbitrary numbers (though only a subset are ever issued, no real people's SSNs have "area number" 666 even though these are now random)
  - epcoa 3y ago
    It's not even unique (outside of a process) nor exclusive.
randomdata 3y ago
> Why they were ever called file descriptors in the first place Human laziness, no doubt. What you refer to as "file descriptor" is really a pointer to a file descriptor. It is likely that over time "file descriptor pointer" or "file descriptor handle" was shortened, and then ultimately accepted into the lexicon.
- dataflow 3y ago
  > Everything they can refer to is a file. In what sense is (say) a signalfd a "file"? How about a pidfd?
  - randomdata 3y ago
    Originally, a file in computing referred to a group of punch cards stored in a box. If this is the definition you hold on to, then signalfd and pidfd do not represent a file. In fact, by that definition nothing in modern computing is a file. However, as the technology evolved and punch cards went out of style, everyone (except maybe you) accepted "file" as an abstract representation of said box. signalfd and pidfd fit within that abstraction. Should I preemptively start into your next question of why Linux has tty when there is no teletype to be found?
    - simiones 3y ago
      I don't think using the term "file" for any kernel-managed resource is common outside of Unix terminology. It is certainly not the terminology of Windows. It is not even really true on modern Linux either, nor was it ever fully true in Unix land - Plan9 is probably the only OS that really went for "everything is a file" to the utmost degree. For example, in either Unix or Linux, a socket is not really a file, even though an open socket has an associated fd. But you can't open a new connection by using open()/read()/write() on any Unix or Linux system (you can in Plan9). So these are not really files. Similarly, most devices expose special ioctl() codes to perform operations on them and barely interact with read() or write().
      - 3y ago
nineteen999 3y ago
> file descriptors are... neither files nor descriptors This is a pretty modern and userspace-centric view of file descriptors IMHO. The "description" part is in the file description table on the kernel side of the userspace/kernel boundary (see struct file[1]) for what are extremely obvious reasons. Up to V7 UNIX (1973-1979[2,3]), the file description table could literally only reference a file on disk, UNIX domain/TCP/UDP sockets weren't introduced until 4.2BSD. Your gentle rant makes sense from a modern point of view of course, but we need to keep in mind that the UNIX design is over 50 years old now. You could argue that the 4.2BSD people should have used different tables/names rather than overload the file description table but that ship has sailed and here we are. [1]https://chenshuo.com/notes/kernel/file-descriptor-table/ https://chenshuo.com/notes/kernel/file-descriptor-table/ [2]https://www.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/file.h https://www.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/file.h [3]https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/file.h https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sy...
- gpderetta 3y ago
  Pipes were created quite early in the unix development though. I assume they had an entry in the file description table. Same for ttys.
  - jetbalsa 3y ago
    Looking at [2], They did not. Only has FWRITE and FREAD, later on in the linked v7 they added FPIPE, not sure how TTY's are handled back then, but I bet it was a device driver of some kind with the real basic BIOS those systems had.
silon42 3y ago
Full names are "opened file descriptors" and "opened file handled"... they typically have current file position of an opened stream.

akira2501 3y ago

They describe the state of a stream. Which are flags and a current offset at a minimum. On linux you can examine /proc/<pid>/fdinfo/<fd> to see what it 'describes' precisely.

dataflow 3y ago
The file descriptor doesn't describe anything. It's like your social security number, it's merely a unique identifier for something else. Does your SSN describe you as a human? What do I know about you as a human after I hear your SSN? Absolutely nothing.
- akira2501 3y ago
  > What do I know about you as a human after I hear your SSN You know what part of the country I was born in, and using that, you can guess my age range. The interface is an opaque number, the implementation describes state, some of which is guaranteed to be present, one of which you can access using lseek(), which is a system call. In this case the state is even completely deterministic.
  - epcoa 3y ago
    > The interface is an opaque number While opaque for a subset of the API, it's not fully opaque since certain assumptions are made by the client based on their value: they are guaranteed to be reused and minimal. What this means is I can do close(0); open(...) to redirect stdin. > the implementation describes state, some of which is guaranteed to be present, one of which you can access using lseek() >> Which are flags and a current offset at a minimum. Uhh... no. Try that with pipes, sockets, FIFOs or any of the myriad other file types, eventfds, signalfds, kqueue, etc there are. Most open fds on a data center server likely don't meet your criteria. Even POSIX disagrees for the concept you are trying to convey cf "file description". https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
    - akira2501 3y ago
      > Even POSIX disagrees for the concept you are trying to convey cf "file description" You should have kept reading: 3.258 Open File Description A record of how a process or group of processes is accessing a file. Each file descriptor refers to exactly one open file description, but an open file description can be referred to by more than one file descriptor. The file offset, file status, and file access modes are attributes of an open file description.
      - epcoa 3y ago
        "The file offset, file status, and file access modes are attributes of an open file description" That says file description there buddy, not descriptor. The two are defined separately, that is all. The single integer does not describe state in the way those terms are typically used; we have clearer vocabulary: refers, points to, etc that's fine. But it is a distinction with a difference. (They're not even unique). Edit: yeah, it says refers, not describes.
        akira2501 3y ago
        And, read more carefully, emphasis added: "Each file descriptor refers to exactly one open file description" Different integers are always unique. It's the file description that isn't: "but an open file description can be referred to by more than one file descriptor." You're attempting to make a huge distinction between interface and implementation. I can't rightly determine why.
  - tialaramex 3y ago
    Actually in the modern era SSNs are assigned randomly. Anybody born before about 2011 who hasn't needed a re-assignment will indeed have SSNs which in some sense contain information, but after this date they're just arbitrary numbers (though only a subset are ever issued, no real people's SSNs have "area number" 666 even though these are now random)
- epcoa 3y ago
  It's not even unique (outside of a process) nor exclusive.

randomdata 3y ago

> Why they were ever called file descriptors in the first place Human laziness, no doubt. What you refer to as "file descriptor" is really a pointer to a file descriptor. It is likely that over time "file descriptor pointer" or "file descriptor handle" was shortened, and then ultimately accepted into the lexicon.

dataflow 3y ago
> Everything they can refer to is a file. In what sense is (say) a signalfd a "file"? How about a pidfd?
- randomdata 3y ago
  Originally, a file in computing referred to a group of punch cards stored in a box. If this is the definition you hold on to, then signalfd and pidfd do not represent a file. In fact, by that definition nothing in modern computing is a file. However, as the technology evolved and punch cards went out of style, everyone (except maybe you) accepted "file" as an abstract representation of said box. signalfd and pidfd fit within that abstraction. Should I preemptively start into your next question of why Linux has tty when there is no teletype to be found?
  - simiones 3y ago
    I don't think using the term "file" for any kernel-managed resource is common outside of Unix terminology. It is certainly not the terminology of Windows. It is not even really true on modern Linux either, nor was it ever fully true in Unix land - Plan9 is probably the only OS that really went for "everything is a file" to the utmost degree. For example, in either Unix or Linux, a socket is not really a file, even though an open socket has an associated fd. But you can't open a new connection by using open()/read()/write() on any Unix or Linux system (you can in Plan9). So these are not really files. Similarly, most devices expose special ioctl() codes to perform operations on them and barely interact with read() or write().
    - 3y ago

nineteen999 3y ago

> file descriptors are... neither files nor descriptors This is a pretty modern and userspace-centric view of file descriptors IMHO. The "description" part is in the file description table on the kernel side of the userspace/kernel boundary (see struct file[1]) for what are extremely obvious reasons. Up to V7 UNIX (1973-1979[2,3]), the file description table could literally only reference a file on disk, UNIX domain/TCP/UDP sockets weren't introduced until 4.2BSD. Your gentle rant makes sense from a modern point of view of course, but we need to keep in mind that the UNIX design is over 50 years old now. You could argue that the 4.2BSD people should have used different tables/names rather than overload the file description table but that ship has sailed and here we are. [1]https://chenshuo.com/notes/kernel/file-descriptor-table/ https://chenshuo.com/notes/kernel/file-descriptor-table/ [2]https://www.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/file.h https://www.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/file.h [3]https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/file.h https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sy...

gpderetta 3y ago
Pipes were created quite early in the unix development though. I assume they had an entry in the file description table. Same for ttys.
- jetbalsa 3y ago
  Looking at [2], They did not. Only has FWRITE and FREAD, later on in the linked v7 they added FPIPE, not sure how TTY's are handled back then, but I bet it was a device driver of some kind with the real basic BIOS those systems had.

silon42 3y ago

Full names are "opened file descriptors" and "opened file handled"... they typically have current file position of an opened stream.