Потому, что это не сетевые карты. Очевидно же.

там нет не только сетевых интерфейсов, если что.

А сетевые карты там есть? Где? А кто управляет сущностями типа «сетевой интерфейс»? Какой модуль?

А как ты себе представляешь работу с сетевым интерфейсом, если бы для него был бы выделен файл в /dev?

Я в этом топеге вопросы задаю )

потому что разработано было гораздо позже чем сам unix?

Create(«/dev/tcp/client:192.168.1.0:3128»);

write(«get http://sex.com/ http/1 0\nhost: sex.com\n\n»);

Почитай вот эту статью: http://www.opennet.ru/base/net/iproute2_cebka.txt.html

Постарайся прочитать целиком, даже если будешь мало понимать в процессе чтения. После этого у тебя должно появится некое представление о том, что такое сетевой интерфейс и как он устроен.

Create

Фу таким быть. Это ж вин32апи!

Обязательно нужно с ключом, обозначающим не использовать ленту телетайпа! А то вдруг у нас телетайпнет

Ну вот простейший вопрос - почему их нет в dev? Почему за ними такая особенная философия стоит?

потому-что в Linux все сущности == файлы. Ну а eth0 это не сущность, а среда передачи. Т.е. она не является хранилищем информации, даже временным, хотя и является средой передачи информации. Т.е. ей нет места в файловой системе потому-же, почему нет места для /dev/SATA, или /dev/usb.

а зачем? для bash /dev/{tcp|udp}/<host>/<port> и так работает

потому-что в Linux все сущности == файлы. Ну а eth0 это не сущность, а среда передачи. Т.е. она не является хранилищем информации, даже временным, хотя и является средой передачи информации

именованные каналы негодуют. man mkfifo

именованные каналы негодуют. man mkfifo

каналы — тоже файлы, т.е. временные хранилища информации. Неименованные тоже. man 7 pipe.

Ты отличай «кусок провода» от «хранилища»

ну-ну, попытайся прочитать чего из канала, не являясь основным читателем. разве что каким-то аналогом tcpdump-а

как ты себе представляешь работу с сетевым интерфейсом, если бы для него был бы выделен файл в /dev?

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

ну-ну, попытайся прочитать чего из канала

это уже частности. Важно, что там оно _может_ хранится, это же труба. А вот в проводе оно не может хранится по определению (да, я знаю, в технике грань смазана, и можно в принципе использовать среду передачи как хранилище, даже интернет можно, но это уже из области извращений ИМХО).

Не везде

я так понял, в силу большого кол-ва специфичных функции

а я так понял, что в силу их ненужности как устройств. А вот если к ethernet подключить HDD, это как будет выглядеть? Ага, криво, костыльно, и непонятно.

А вот если к ethernet подключить HDD, это как будет выглядеть?

Как /dev/sd* когда прокинешь iSCSI

накостылять бы специфичный драйвер да бахнуть блочное устройство.

в проводе - нет. в ядре - да

не везде. но сама идея...

Как /dev/sd* когда прокинешь iSCSI

а зачем тогда /dev/eth?

накостылять бы специфичный драйвер да бахнуть блочное устройство.

вот и я про то, что УСТРОЙСТВО будет файлом, а вот eth тут совсем не нужен (как файл).

в проводе - нет. в ядре - да

что «в ядре»? Предлагаешь хранить в ядре данные пользователя?

а зачем тогда /dev/eth?

ifconfig /dev/eth0 192.168.0.66/24 gw 192.168.0.1

Точно так же как и с другими девайсами.

Как-то реально слабо представляю. Получается, начиная со второго уровня вся работа с сетью была в юзер-спейсе? Как, например, можно было повесить два сервиса на разные порты? Допустим, один сервис прочитал из интерфейса входящие данные, а они должны были второму достаться.

Но особого смысла нет потому что, в отличие от файлов и блочных устройств, открытие ethX как файла спорный вопрос. Поэтому лучше использовать какой-нить libpcap.

а где они, по-твоему, хранятся? что сокет, что пайп - один хрен в ядре данные держат, чтобы отдать читателю. другое дело, что ведро с этими данными несколько по-разному обращается, но идея - одна и та же. и никоим образом не завязана на

не сущность, а среда передачи

Получается, начиная со второго уровня вся работа с сетью была в юзер-спейсе?

Не обязательно, см. пример ниже :)

Как, например, можно было повесить два сервиса на разные порты?

Можно как в cgroups сделать:

mkdir -p  /dev/eth0/tcp/
touch /dev/eth0/tcp/:80
cat /dev/eth0/tcp/:80
..

PS думаю, это не я придумал. Возможно, это смесь фич bash, cgroups, какого-нить plan9 итп.

открытие ethX как файла спорный вопрос

не спорный, а бессмысленный. /dev/ethX нужен разве что для управления сетевухой, как железякой. иначе файлы устройств надо привязывать к конкретным сокетам

См. пост выше твоего. Я предлагаю не ограничиваться старой интерпретаций /dev как помойки файлов с (major, minor) номерами.

ну или так, согласен

вот если к ethernet подключить HDD, это как будет выглядеть?

кто сказал ATA over Ethernet? :-)

// я утрирую конечно, ибо это всё-таки отдельный протокол, но суть ты понял

Как /dev/sd* когда прокинешь iSCSI

а зачем тогда /dev/eth?

ifconfig /dev/eth0 192.168.0.66/24 gw 192.168.0.1

ЩИТО? HDD станет Сетью?

что сокет, что пайп - один хрен в ядре данные держат

в каком ядре? В обычной памяти.

я утрирую конечно, ибо это всё-таки отдельный протокол, но суть ты понял

дык о том я и говорил. Просто eth это не устройство по типу как hdd, и потому-то их и нет в dev.

не кури больше такого

я так понял, в силу большого кол-ва специфичных функции

Гораздо прозаичнее - в линуксе интерфейсы стали динамическими в те мохнатые времена, когда никаких средств управления /dev ещё и в проекте не было

Тогда это будет просто особая файловая система. Хоть сейчас можно сделать, если сильно нужно. А файл устройства при этом всё равно не нужен. А для других устройств таки нужны, поэтому помойка (major, minor) нужна.

Хотя, конечно, можно сделать, чтобы socket(2) и так далее на самом деле были не системными вызовами, а работали через /dev/eth, но вряд ли это может быть сильно полезно.

дело в том, что звуковуха тоже хранилищем не является, а в /dev присутствует.

А для других устройств таки нужны

Почему?

Сейчас тебе скажут, что в ней хранится звук, она как труба...

Потому что здесь так заведено.

4.2 :)

Т.е. ей нет места в файловой системе потому-же, почему нет места для /dev/SATA, или /dev/usb.

drakmail@Lucky:~$ ls -lah /dev/usb
итого 0
drwxr-xr-x  2 root root      60 Июл 29 17:29 ./
drwxr-xr-x 17 root root     14K Июл 29 13:30 ../
crw-------  1 root root 180, 96 Июл 29 17:29 hiddev0

Потом с апдейтом сетевой подсистемы от этого ушли т.к., я так понял, в силу большого кол-ва специфичных функции (аля алиасы на интерфейсы, файерволы, очереди, мосты, итд итп) рациональнее было отвязаться от /dev.

Дык похожий зоопарк сейчас в /proc и /sys развешен, не?

не спорный, а бессмысленный. /dev/ethX нужен разве что для управления сетевухой, как железякой.

ioctl'ы дергать можно, как на wifi. Скан там, SSID поставить, шифрование задать...

Дык похожий зоопарк сейчас в /proc и /sys развешен, не?

Да. И вот непонятно что лучше — плодить ioctl или же создавать спецфайлы типа (как ты пишиешь ниже) /dev/eth0/wifi_scan . Я вот не люблю ioctl и вообще сишные интерфейсы потому что если ты пишешь проги не на си то у тебя проблемы. Я пишу в основном на питоне. И всё время проблемы. Приходится писать прослойки на сях. Да, в питоне есть возможность прямого вызова библиотечных функций (ctypes итп), только вот вся интерфейсная часть в хедерах либ/ядра. И эти хедеры ещё отличаются на разных версиях ядра и на разных плафтофрмах (аля x86 vs amd64). И получается что перед вызовом программы нам надо

1) иметь девелоперские версии пакетов чтобы были хедеры

2) парсить их

И вот с парсингом полная попа из-за макросов и извратных сишных конструкций. Так что, наверно, лучше иметь что-то вроде /sys вместо /dev

И вот непонятно что лучше — плодить ioctl

В LKD насколько помню сискол ioctl приводится как пример чего *не* надо делать.

И получается что перед вызовом программы нам надо
1) иметь девелоперские версии пакетов чтобы были хедеры

Это специфика интерпретируемого языка в общем? В смысле, для С хедеры были бы для сборки нужны, не для вызова.

2) парсить их

Ну был бы разбор (текстового?) /dev/eth0/wifi_scan. Тоже надо было бы иметь описание формата для разных версий ядра, которые или те же системные хедеры должны описывать, или вообще каждое приложение с собой таскать.

В порядке бреда, интересен вариант с общей шиной типа (k)dbus. Хедеры нужны только для неё самой — раз, строгой типизации для конкретной операции нет — два. То есть когда в новом ядре для каждой WiFi станции прийдет новое поле, старый софт это не сломает. Текстовый вариант в этом смысле похож, но гибкости всё-таки меньше, имхо.