Perché le interfacce di rete non sono in / dev come gli altri dispositivi?


70

Sono per lo più curioso, ma perché le interfacce di rete non sono in / dev? Esistono altri tipi di dispositivi che non sono rappresentati come nodo in / dev?


2
Ho visto almeno un articolo / rant su come tutto in Unix non sia un file nonostante il mantra, e cita questo problema. Non riesco a trovarlo ora, ma probabilmente era un articolo su Plan 9 o GNU Hurd.
Shawn J. Goff,

3
Almeno in Solaris, ci sono dispositivi di interfaccia di rete in / dev (/ dispositivi in ​​realtà).
jlliagre,

2
Tutto ciò che in Unix è un file non significa necessariamente che si comporti in questo modo nell'intera area utente, solo che le API sottostanti operano in modo corretto e uniforme sui descrittori di file. Quando apri un socket, ad esempio, puoi usare read()e fare write()lo stesso di un file, ma l'utilità funziona recv()e send()fa molto più lavoro per te.
jgoldschrafe,

1
Questa era una domanda che mi ponevo da anni. Grazie per avermelo chiesto e per le persone che hanno risposto!
Dolanor

Risposte:


43

Su molti dispositivi, le operazioni principali sono l'invio di byte dal computer a una periferica o la ricezione di byte da una periferica del computer. Tali dispositivi sono simili ai tubi e funzionano bene come dispositivi a caratteri . Per le operazioni che non leggono e scrivono (come il controllo del flusso su una linea seriale), il dispositivo fornisce comandi ad hoc chiamati ioctl .

Alcuni dispositivi sono molto simili ai normali file: sono costituiti da un numero finito di byte e ciò che scrivi in ​​una determinata posizione può in seguito essere letto dalla stessa posizione. Questi dispositivi sono chiamati dispositivi a blocchi .

Le interfacce di rete sono più complesse: ciò che leggono e scrivono non sono byte ma pacchetti. Mentre sarebbe ancora possibile utilizzare la solita interfaccia con reade write, sarebbe imbarazzante: presumibilmente ogni chiamata a writeavrebbe inviato un pacchetto e ogni chiamata a readavrebbe ricevuto un pacchetto (e se il buffer è troppo piccolo per adattarsi al pacchetto, il pacchetto andrebbe perso).

Le interfacce di rete potrebbero esistere solo come dispositivi che forniscono ioctl. In effetti, questo è ciò che fanno alcune varianti di unix, ma non Linux. C'è qualche vantaggio in questo approccio; ad esempio, su Linux, le interfacce di rete potrebbero sfruttare udev . Ma i vantaggi sono limitati, motivo per cui non è stato fatto.

La maggior parte delle applicazioni relative alla rete non si preoccupano delle singole interfacce di rete, ma funzionano a un livello superiore. Ad esempio, un browser Web desidera stabilire connessioni TCP e un server Web desidera ascoltare le connessioni TCP. A tal fine, ciò che sarebbe utile sono dispositivi per protocolli di rete di alto livello, ad es

{ 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 effetti ksh e bash forniscono una tale interfaccia per i client TCP e UDP. In generale, tuttavia, le applicazioni di rete sono più complesse delle applicazioni che accedono ai file. Mentre la maggior parte degli scambi di dati avviene con chiamate analoghe a reade write, stabilire la connessione richiede più informazioni di un semplice nome di file. Ad esempio, l'ascolto delle connessioni TCP richiede due passaggi: uno da eseguire all'avvio dell'ascolto del server e uno da eseguire ogni volta che un client si connette. Tali passaggi extra non si adattano bene all'API dei file, che è il motivo principale per cui la rete ha una propria API.

Un'altra classe di dispositivi che in genere non ha voci /devsu Linux (ma su alcune altre varianti unix) sono gli adattatori video. In linea di principio, semplici adattatori video potrebbero essere esposti come dispositivi framebuffer , che potrebbero essere dispositivi a blocchi costituiti da blocchi che rappresentano il colore di ciascun pixel. Gli adattatori video accelerati potrebbero essere rappresentati come dispositivi a caratteri su cui le applicazioni inviano comandi. Qui, lo svantaggio dell'interfaccia del dispositivo è che è lento: l'applicazione di visualizzazione (in pratica un server X) dovrebbe effettuare chiamate del kernel ogni volta che visualizza qualcosa. Quello che succede invece è che il server X per lo più scrive direttamente nella memoria della scheda video, perché è più veloce.


2
In effetti, gli adattatori video accelerati vengono esportati come chardevs tramite DRI in Linux. Le operazioni di I / O dei file non sono necessarie read/ writeneanche; è possibile utilizzare mmapper i file mappati e l'accesso diretto alla memoria del dispositivo.
minmaxavg,

11

Puoi trovarlo nella /sys/class/netdirectory. it Link simbolico ad altri file in /sys/device/../../, di seguito è riportato l'output della mia macchina virtuale (kernel Linux 3.10). E puoi usare il comando udevadm info <filename>per esaminare il suo attributo

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

Benvenuto in U&L. Usa sempre i backquotes attorno al codice inline, specialmente se lo usi <>come altrimenti che viene interpretato come markup. (potresti anche voler cambiare il tuo nome per iniziare con una trascrizione ASCII, poiché le persone con tastiere semplici avranno difficoltà a digitare il primo carattere del tuo nome in risposta a eventuali commenti che fai)
Anthon

9

Il modo "Network Level Interface" (TLI) di AT & T / Solaris di fare reti TCP / IP ha file speciali come "/ dev / tcp" o "/ dev / udp". Il programmatore apre quel file speciale per ottenere un socket di una famiglia di protocolli appropriata. Penso che sia per questo che devi avere "-lnsl" durante la compilazione di un programma che utilizza socket su Solaris: al di sotto di tutto c'è TLI.


4
Anche Linux ha /dev/tcpe /dev/udp, sebbene molti kernel lo abbiano disabilitato.
Bahamat,

3

Mentre tradizionalmente Linux non è stato completamente compatibile posix, figuriamoci anche seguire qualsiasi tipo di standard Open Group (al di fuori forse LSB). Ci sono stati tentativi di trasferire più funzionalità UNIX su Linux.

Glendix è uno di questi progetti che offre una porta del filesystem virtuale / net di Plan9 che ti permette di fare esattamente come descrivi.

Plan9 Port / net filesystem su linux

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.