Почему сетевые интерфейсы не находятся в / dev, как другие устройства?

Мне в основном любопытно, но почему нет сетевых интерфейсов в / dev? Существуют ли другие виды устройств, которые не представлены в виде узла в / dev?

На многих устройствах основными операциями являются отправка байтов с компьютера на периферийное устройство или получение байтов с периферийного устройства на компьютере. Такие устройства похожи на трубы и хорошо работают как символьные устройства . Для операций, которые не читают и не записывают (например, управление потоком данных по последовательной линии), устройство предоставляет специальные команды, называемые ioctl .

Некоторые устройства очень похожи на обычные файлы: они состоят из конечного числа байтов, и то, что вы пишете в заданной позиции, позже может быть прочитано из той же позиции. Эти устройства называются блочными устройствами .

Сетевые интерфейсы более сложны: они читают и пишут не байты, а пакеты. Хотя все еще можно было бы использовать обычный интерфейс с readи write, это было бы неудобно: предположительно, каждый вызов writeотправлял бы пакет, и каждый вызов readполучал бы пакет (и если буфер слишком мал для пакета, чтобы уместиться, пакет будет потерян).

Сетевые интерфейсы могут существовать только в качестве устройств ioctl. Фактически, это то, что делают некоторые варианты Unix, но не Linux. У этого подхода есть некоторое преимущество; например, в Linux сетевые интерфейсы могут использовать udev . Но преимущества ограничены, поэтому это не было сделано.

Большинство сетевых приложений не заботятся об отдельных сетевых интерфейсах, они работают на более высоком уровне. Например, веб-браузер хочет устанавливать TCP-соединения, а веб-сервер хочет прослушивать TCP-соединения. Для этой цели было бы полезно использовать устройства для сетевых протоколов высокого уровня, например

{ 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

Фактически, ksh и bash предоставляют такой интерфейс для клиентов TCP и UDP. В целом, однако, сетевые приложения более сложны, чем приложения для доступа к файлам. Хотя большинство обменов данными осуществляется с помощью вызовов, аналогичных readи write, для установления соединения требуется больше информации, чем просто имя файла. Например, прослушивание TCP-соединений выполняется в два этапа: один из них выполняется, когда сервер начинает прослушивание, и один - при каждом подключении клиента. Такие дополнительные шаги плохо вписываются в файловый API, что является основной причиной, по которой сеть имеет свой собственный API.

Другой класс устройств, которые обычно не имеют записей в /devLinux (но есть в некоторых других вариантах Unix), это видеоадаптеры. В принципе, простые видеоадаптеры могут быть представлены как устройства кадрового буфера , которые могут быть блочными устройствами, состоящими из блоков, представляющих цвет каждого пикселя. Ускоренные видеоадаптеры могут быть представлены как символьные устройства, на которые приложения отправляют команды. Здесь недостатком интерфейса устройства является то, что он медленный: приложение отображения (на практике X-сервер) должно было бы выполнять вызовы ядра при каждом отображении чего-либо. Вместо этого происходит то, что X-сервер в основном пишет непосредственно в память видеоадаптера, потому что он быстрее.

Вы можете найти его в /sys/class/netкаталоге. Это символическая ссылка на другой файл /sys/device/../../, следующий - вывод моей виртуальной машины (ядро Linux 3.10). И вы можете использовать команду, udevadm info <filename>чтобы просмотреть его атрибут

lrwxrwxrwx. 1 root root 0 Apr  3 13:38 ens33 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33

В AT & T / Solaris "TLI" для создания сетей TCP / IP есть специальные файлы, такие как "/ dev / tcp" или "/ dev / udp". Программист открывает этот специальный файл, чтобы получить сокет соответствующего семейства протоколов. Я думаю, именно поэтому вы должны иметь "-lnsl" при компиляции программы, которая использует сокеты в Solaris: под всем этим стоит TLI.

Хотя традиционно Linux не был полностью совместимым с posix, не говоря уже о том, чтобы следовать любым стандартам Open Group (за исключением, возможно, LSB). Были попытки перенести больше функциональности UNIX в Linux.

Glendix - один из таких проектов, который предлагает порт виртуальной файловой системы / net от Plan9, который позволяет вам делать то же самое, что и вы.

Plan9 Порт / сетевая файловая система для Linux