Чому мережеві інтерфейси не в / dev, як інші пристрої?

70

Мені найбільше цікаво, але чому мережеві інтерфейси в / dev не є? Чи існують інші типи пристроїв, які не представлені у вигляді вузла під / dev?

devices udev

— andyortlieb
джерело

2

Я бачив принаймні одну статтю / рент про те, як все в Unix не є файлом, незважаючи на мантру, і це цитує цю проблему. Зараз я не можу його знайти, але це, мабуть, стаття про План 9 або GNU Hurd.

— Шон Дж. Гофф

3

Принаймні, під Solaris є пристрої мережевого інтерфейсу під / dev (/ фактично пристроями).

— jlliagre

2

Все, що в Unix є файлом, не обов'язково означає, що він поводиться так у всій країні користувачів, лише те, що основні API працюють справно і рівномірно в дескрипторах файлів. При відкритті сокета, наприклад, ви можете використовувати read()і write()так само, як ви б на файл, але функція корисності recv()і send()зробити набагато більше біганини для вас.

— jgoldschrafe

1

Це було питання, яке я ставив собі роками. Дякуємо за запитання, а люди відповіли!

— Доланор

43

На багатьох пристроях основними операціями є пересилання байтів з комп'ютера на периферію або отримання байтів з периферії на комп'ютер. Такі пристрої схожі на труби і добре працюють як символьні пристрої . Для операцій, які не читають і не записують (наприклад, контроль потоку в послідовному рядку), пристрій надає спеціальні команди під назвою 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 здебільшого записує безпосередньо у пам'ять відеоадаптера, оскільки це швидше.

— Жиль
джерело

2

Насправді, прискорені відеоадаптери будуть експортовані як chardevs через DRI в Linux. Операції вводу / виводу файлів не обов'язково read/ writeабо; Ви можете використовувати mmapдля відображення файлів і прямий доступ до пам'яті пристрою.

— minmaxavg

11

Ви можете знайти його в /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

— чаок лу
джерело

Ласкаво просимо до U&L. Завжди використовуйте зворотні котирування навколо вбудованого коду, особливо якщо ви використовуєте <>інакше, що трактується як розмітка. (ви також можете змінити своє ім’я, щоб почати транскрипцію ASCII, оскільки людям із простими клавіатурами буде важко набрати перший символ вашого імені у відповідях на будь-які ваші коментарі)

— Антон,

9

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

— Брюс Едігер
джерело

4

У Linux також є, /dev/tcpі /dev/udpхоча більшість ядер вимкнено його.

— bahamat

3

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

Glendix - один з таких проектів, який пропонує порт / віртуальної файлової системи / net від Plan9, який дозволяє робити так само, як і описувати.

Файлова система Plan9 Port / net для Linux

— Дуайт Спенсер
джерело