Dlaczego interfejsy sieciowe nie są w / dev jak inne urządzenia?

70

Jestem głównie ciekawy, ale dlaczego interfejsy sieciowe nie są w / dev? Czy istnieją inne rodzaje urządzeń, które nie są reprezentowane jako węzły w / dev?

devices udev

— andyortlieb
źródło

2

Widziałem przynajmniej jeden artykuł / rant na temat tego, że wszystko w Uniksie nie jest plikiem pomimo mantry i przytacza ten problem. Nie mogę go teraz znaleźć, ale prawdopodobnie był to artykuł o Planie 9 lub GNU Hurd.

— Shawn J. Goff

3

Przynajmniej w systemie Solaris istnieją interfejsy sieciowe urządzeń w / dev (/ devices faktycznie).

— jlliagre

2

Wszystko w Uniksie jest plikiem, co niekoniecznie oznacza, że zachowuje się w ten sposób w całej przestrzeni użytkownika, tylko że podstawowe interfejsy API działają zdrowo i jednolicie na deskryptorach plików. Po otwarciu gniazda, na przykład, można użyć read()i write()tak samo jak byś na pliku, ale funkcje użytkowe recv()i send()zrobić dużo więcej zdobyciem dla Ciebie.

— jgoldschrafe

1

To pytanie zadawałem sobie od lat. Dziękujemy za pytanie i za odpowiedź!

— Dolanor,

43

Na wielu urządzeniach głównymi operacjami są wysyłanie bajtów z komputera na urządzenie peryferyjne lub odbieranie bajtów z urządzenia peryferyjnego na komputerze. Takie urządzenia są podobne do potoków i działają dobrze jako urządzenia postaci . W przypadku operacji, które nie odczytują i nie zapisują (takich jak kontrola przepływu na linii szeregowej), urządzenie udostępnia polecenia ad-hoc o nazwie ioctl .

Niektóre urządzenia są bardzo podobne do zwykłych plików: składają się ze skończonej liczby bajtów, a to, co piszesz w danej pozycji, można później odczytać z tej samej pozycji. Urządzenia te nazywane są urządzeniami blokowymi .

Interfejsy sieciowe są bardziej złożone: to, co odczytują i zapisują, to nie bajty, ale pakiety. Chociaż nadal byłoby możliwe użycie zwykłego interfejsu z, readi writebyłoby to niezręczne: przypuszczalnie każde wywołanie do writewysłałoby pakiet, a każde wywołanie do readodebrałoby pakiet (a jeśli bufor jest zbyt mały, aby pomieścić pakiet, pakiet zostanie utracony).

Interfejsy sieciowe mogą istnieć wyłącznie jako urządzenia ioctl. W rzeczywistości robią to niektóre warianty unixowe, ale nie Linux. Takie podejście ma pewną zaletę; na przykład w systemie Linux interfejsy sieciowe mogą wykorzystywać udev . Ale zalety są ograniczone, dlatego nie zostało to zrobione.

Większość aplikacji sieciowych nie dba o poszczególne interfejsy sieciowe, działają one na wyższym poziomie. Na przykład przeglądarka internetowa chce nawiązywać połączenia TCP, a serwer sieciowy chce nasłuchiwać połączeń TCP. W tym celu przydatne byłyby urządzenia do protokołów sieciowych wysokiego poziomu, np

{ 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

W rzeczywistości ksh i bash zapewniają taki interfejs dla klientów TCP i UDP. Ogólnie jednak aplikacje sieciowe są bardziej złożone niż aplikacje z dostępem do plików. Podczas gdy większość wymiany danych odbywa się przy użyciu połączeń analogicznych do readi write, nawiązanie połączenia wymaga więcej informacji niż tylko nazwy pliku. Na przykład nasłuchiwanie połączeń TCP wymaga dwóch kroków: jednego do wykonania, gdy serwer zaczyna nasłuchiwać, i drugiego do wykonania przy każdym połączeniu klienta. Takie dodatkowe kroki nie pasują dobrze do interfejsu API pliku, co jest głównym powodem, dla którego sieć ma swój własny interfejs API.

Inną klasą urządzeń, które zwykle nie mają wpisów w /devLinuksie (ale w niektórych innych wariantach unixowych) są karty wideo. Zasadniczo proste karty wideo mogą być widoczne jako urządzenia buforujące ramki , które mogą być urządzeniami blokowymi wykonanymi z bloków reprezentujących kolor każdego piksela. Przyspieszone karty wideo mogą być reprezentowane jako urządzenia znakowe, na które aplikacje wysyłają polecenia. Wadą interfejsu urządzenia jest to, że działa wolno: aplikacja wyświetlająca (w praktyce serwer X) będzie musiała wykonywać wywołania jądra za każdym razem, gdy cokolwiek wyświetla. Zamiast tego serwer X zapisuje głównie bezpośrednio w pamięci karty wideo, ponieważ jest szybszy.

— Gilles
źródło

2

W rzeczywistości przyspieszone karty wideo są eksportowane jako pliki chardev za pośrednictwem DRI w systemie Linux. Operacje we / wy pliku nie są konieczne read/ writealbo; możesz użyć mmapdo mapowania plików i bezpośredniego dostępu do pamięci urządzenia.

— minmaxavg

11

Znajdziesz go w /sys/class/netkatalogu. it Symboliczne łącze do innego pliku /sys/device/../../, poniżej znajduje się wyjście mojej maszyny wirtualnej (jądro Linuksa 3.10). I możesz użyć polecenia, udevadm info <filename>aby przejrzeć jego atrybut

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

— chaoqun lu
źródło

Witamy w U&L. Zawsze używaj cudzysłowów wokół kodu wbudowanego, zwłaszcza jeśli używasz <>inaczej, co jest interpretowane jako znaczniki. (możesz również zmienić nazwę, aby rozpocząć z transkrypcji ASCII, jak ludzie z prostych klawiatur będzie miał trudności wpisując pierwszą literę nazwy w odpowiedzi na wszelkie uwagi zrobić)

— Anthon

9

Sposób ATI T / Solaris „Transport Level Interface” (TLI) do tworzenia sieci TCP / IP ma specjalne pliki, takie jak „/ dev / tcp” lub „/ dev / udp”. Programista otwiera ten specjalny plik, aby uzyskać gniazdo odpowiedniej rodziny protokołów. Myślę, że dlatego musisz mieć „-lnsl” podczas kompilacji programu korzystającego z gniazd w Solarisie: pod tym wszystkim jest TLI.

— Bruce Ediger
źródło

4

Linux również ma /dev/tcpi /dev/udpchociaż większość jąder ma to wyłączone.

— bahamat

3

Chociaż tradycyjnie Linux nie był w pełni kompatybilny z POSIX-em, nie mówiąc już o przestrzeganiu jakichkolwiek standardów Open Group (poza być może LSB). Podjęto próby przeniesienia większej liczby funkcji UNIX do systemu Linux.

Glendix jest jednym z takich projektów, który oferuje port wirtualnego systemu plików / net z Plan9, który pozwala robić to, co opisujesz.

Plan9 Port / net system plików do systemu Linux

— Dwight Spencer
źródło