Everything is a file - Wikipedia
Jump to content
Search
Search
Donate
Create account
Log in
Personal tools
Donate
Create account
Log in
Everything is a file
4 languages
Deutsch<br>Español<br>Lombard<br>Українська
Edit links
From Wikipedia, the free encyclopedia
Unix philosophy
"Everything is a file" is an approach to interface design in Unix derivatives.<br>While this turn of phrase does not as such figure as a Unix design principle or philosophy,<br>it is a common way to analyse designs, and informs the design of new interfaces in a way that prefers, in rough order of import:
representing objects as file descriptors instead of alternatives like abstract handles or names,
operating on the objects with standard input/output operations, returning byte streams to be interpreted by applications (rather than explicitly structured data), and
allowing the usage or creation of objects by opening or creating files in the global filesystem name space.
The lines between the common interpretations of "file" and "file descriptor" are often blurred when analysing Unix, and nameability of files is the least important part of this principle; thus, it is sometimes described as "Everything is a file descriptor" .[1][2][3]
This approach is interpreted differently with time, philosophy of each system, and the domain to which it's applied.<br>The rest of this article demonstrates notable examples of some of those interpretations, and their repercussions.
Objects as file descriptors<br>[edit]
Under Unix, a directory can be opened like a regular file, containing fixed-size records of (i-node, filename),<br>but directories cannot be written to directly, and are modified by the kernel as a side-effect of creating and removing files within the directory.[4]
Some interfaces only follow a subset of these guidelines, for example pipes do not exist on the filesystem — pipe() creates a pair of unnameable file descriptors.[5]<br>The later invention of named pipes (FIFOs) by POSIX fills this gap.
This does not mean that the only operations on an object are reading and writing:<br>ioctl() and similar interfaces allow for object-specific operations (like controlling tty characteristics),<br>directory file descriptors can be used to alter path look-ups (with a growing number of *at() system call variants like openat()[6]) or to change the working directory to the one represented by the file descriptor,[7] in both cases preventing race conditions and being faster than the alternative of looking up the entire path.[8]
Socket file descriptors require configuration (setting the remote address and connecting) after creation before being used for I/O.<br>A server socket may not be used for I/O directly at all —<br>in connection-based protocols, bind() assigns a local address to a socket,<br>and listen() uses that socket to wait until a remote process connects,<br>then returns a new socket file descriptor representing that direct bidirectional connection.
This approach allows management of objects used by a program in a standardised manner, just like any other file —<br>after binding to an address privileges may be dropped,<br>the server socket may be distributed among many processes by fork()ing<br>(respectively closed in subprocesses that should not have access),<br>or the individual connections' sockets may be given as standard input/output to specialised handlers for those connections,<br>as in the super-server/CGI/inetd paradigms.
Many interfaces present in early Unixes that do not use file descriptors became duplicated in later designs:<br>the alarm()/setitimer() system calls schedule the delivery of a signal after the specified time elapses;<br>this timer is inherited by children, and persists after exec().<br>The POSIX timer_create() API serves a similar function, but destroys the timer in child processes and on exec();<br>these timers identified by opaque handles.<br>Both interfaces always deliver their completions asynchronously,<br>and cannot be poll()ed/select()ed,<br>making their integration into a complex event loop more difficult.
The timerfd design (originally found in Linux),<br>turns each timer object into a file descriptor,<br>which can be individually observed with poll() &c. and whose inheritance to child processes can be controlled with the standard close()/CLOEXEC/CLOFORK controls.
While the POSIX API has timer_getoverrun() that returns how many times the timer elapsed, this is returned as the result of read() from a timerfd.<br>This operation blocks, so waiting until a timerfd elapses is as easy as reading from it. There is no way to atomically do this with classic Unix or POSIX timers.<br>The timer can be inspected non-blockingly by performing a non-blocking read (a standard I/O operation).
Objects in the filesystem namespace<br>[edit]
Special file types<br>[edit]
Device special files are a defining characteristic of Unix:<br>initially, opening a regular file with i-node number ≤40 (traditionally stored under /dev) instead returned a file descriptor corresponding to a device, and handled...