92

I'm mostly curious, but why aren't network interfaces in /dev? Are there any other kinds of devices that aren't represented as a node under /dev?

anatoly techtonik
  • 2,644
andyortlieb
  • 1,021
  • 3
    I've seen at least one article/rant about how everything in Unix is not a file despite the mantra, and it cites this problem. I can't find it now, but it was probably an article about Plan 9 or GNU Hurd. – Shawn J. Goff Oct 24 '11 at 19:23
  • 3
    At least under Solaris, there are network interfaces devices under /dev (/devices actually). – jlliagre Oct 25 '11 at 15:30
  • 2
    Everything in Unix being a file doesn't necessarily mean it behaves that way to the entire userland, just that the underlying APIs operate sanely and uniformly on file descriptors. When you open a socket, for example, you can use read() and write() the same way that you would on a file, but the utility functions recv() and send() do a lot more legwork for you. – jgoldschrafe Oct 26 '11 at 01:48
  • 2
    That was a question I was asking myself for years. Thanks for asking and for people to have replied! – Dolanor Mar 17 '16 at 14:18

4 Answers4

62

On many devices, the main operations are to send bytes from the computer to a peripheral, or to receive bytes from a peripheral on the computer. Such devices are similar to pipes and work well as character devices. For operations that aren't reading and writing (such as flow control on a serial line), the device provides ad-hoc commands called ioctl.

Some devices are very much like regular files: they're made of a finite number of bytes, and what you write at a given position can later be read from the same position. These devices are called block devices.

Network interfaces are more complex: what they read and write is not bytes but packets. While it would still be possible to use the usual interface with read and write, it would be awkward: presumably each call to write would send a packet, and each call to read would receive a packet (and if the buffer is too small for the packet to fit, the packet would be lost).

Network interfaces could exist as devices providing only ioctl. In fact, this is what some unix variants do, but not Linux. There is some advantage to this approach; for example, on Linux, network interfaces could leverage udev. But the advantages are limited, which is why it hasn't been done.

Most network-related applications don't care about individual network interfaces, they work at a higher level. For example, a web browser wants to make TCP connections, and a web server wants to listen for TCP connections. For this purpose, what would be useful is devices for high-level network protocols, e.g.

{ echo $'GET http://www.google.com/ HTTP/1.0\r';
  echo $'Host: www.google.com\r';
  echo $'\r' >&0; cat; } <>/dev/tcp/www.google.com/80

In fact ksh and bash provide such an interface for TCP and UDP clients. In general, however, network applications are more complex than file-accessing applications. While most data exchanges are conducted with calls analogous to read and write, establishing the connection requires more information than just a file name. For example, listening for TCP connections takes two steps: one to be performed when the server starts listening, and one to be performed each time a client connects. Such extra steps don't fit well into the file API, which is the main reason why networking has its own API.

Another class of devices that typically doesn't have entries in /dev on Linux (but does on some other unix variants) is video adapters. In principle, simple video adapters could be exposed as framebuffer devices, which could be block devices made of blocks representing the color of each pixel. Accelerated video adapters could be represented as character devices onto which applications send commands. Here, the drawback of the device interface is that it's slow: the displaying application (in practice, an X server) would need to make kernel calls whenever displaying anything. What happens instead is that the X server mostly writes directly to the memory of the video adapter, because it's faster.

Gilles 'SO- stop being evil'
  • 829,060
  • 4
    In fact, accelerated video adapters are exported as chardevs via DRI in Linux. File I/O operations aren't neccessarily read/write either; you can use mmap for mapped files and direct access to device memory. – minmaxavg Aug 25 '18 at 09:45
  • Well, drives are in /dev even though most applications don't access them directly. – user253751 Sep 10 '21 at 11:06
16

You can find it in /sys/class/net directory. it it Symbolic link to other file in /sys/device/../../, following is my virtual machine (linux kernel 3.10) output. And you can use command udevadm info <filename> to look over its attribute

lrwxrwxrwx. 1 root root 0 Apr  3 13:38 ens33 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33
Anthon
  • 79,293
chaoqun lu
  • 161
  • 1
    Welcome to U&L. Always use backquotes around inline code, especially if you use <> as otherwise that gets interpreted as markup. (you might also want to change your name to start with an ASCII transcription, as people with simple keyboards will have difficulty typing the first character of your name in responses to any comments you make) – Anthon Apr 04 '15 at 06:27
9

The AT&T/Solaris "Transport Level Interface" (TLI) way of doing TCP/IP networking has special files like "/dev/tcp" or "/dev/udp". The programmer opens that special file to get a socket of an appropriate protocol family. I think that's why you have to have "-lnsl" when compiling a program that uses sockets on Solaris: underneath it all it's TLI.

4

While traditionally Linux has not been fully posix compablible, let alone even follow any kind of Open Group standards(outside of maybe LSB). There has been attempts to port more UNIX functionality into Linux.

Glendix is one such project that offers a port of the /net virtual filesystem from Plan9 which allows you to do just as your describing.

Plan9 Port /net filesystem to linux

Dwight Spencer
  • 308