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?

devices udev

— andyortlieb
fonte

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

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.

— Gilles 'SO- smetti di essere malvagio'
fonte

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

— chaoqun lu
fonte

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.

— Bruce Ediger
fonte

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

— Dwight Spencer
fonte