¿Por qué las interfaces de red no están en / dev como otros dispositivos?

70

Tengo curiosidad, pero ¿por qué no están las interfaces de red en / dev? ¿Hay algún otro tipo de dispositivo que no esté representado como un nodo en / dev?

devices udev

— andyortlieb
fuente

2

He visto al menos un artículo / discurso sobre cómo todo en Unix no es un archivo a pesar del mantra, y cita este problema. No puedo encontrarlo ahora, pero probablemente fue un artículo sobre el Plan 9 o GNU Hurd.

— Shawn J. Goff

3

Al menos en Solaris, hay dispositivos de interfaz de red en / dev (/ devices en realidad).

— jlliagre

2

Todo en Unix como un archivo no significa necesariamente que se comporte de esa manera a todo el país de usuarios, solo que las API subyacentes funcionan de manera sensata y uniforme en los descriptores de archivo. Cuando se abre un socket, por ejemplo, puede utilizar read()y write()de la misma manera que lo haría en un archivo, pero las funciones de utilidad recv()y send()hacer mucho más trabajo por usted.

— jgoldschrafe

1

Esa fue una pregunta que me hacía durante años. ¡Gracias por preguntar y por haber respondido!

— Dolanor

43

En muchos dispositivos, las operaciones principales son enviar bytes desde la computadora a un periférico, o recibir bytes desde un periférico en la computadora. Dichos dispositivos son similares a las tuberías y funcionan bien como dispositivos de caracteres . Para las operaciones que no leen ni escriben (como el control de flujo en una línea en serie), el dispositivo proporciona comandos ad-hoc llamados ioctl .

Algunos dispositivos son muy parecidos a los archivos normales: están formados por un número finito de bytes, y lo que escribes en una posición determinada se puede leer más tarde desde la misma posición. Estos dispositivos se llaman dispositivos de bloque .

Las interfaces de red son más complejas: lo que leen y escriben no son bytes sino paquetes. Si bien aún sería posible usar la interfaz habitual con ready write, sería incómodo: presumiblemente, cada llamada a writeenviaría un paquete, y cada llamada a readrecibiría un paquete (y si el búfer es demasiado pequeño para que el paquete se ajuste, el paquete se perdería).

Las interfaces de red podrían existir como dispositivos que solo proporcionan ioctl. De hecho, esto es lo que hacen algunas variantes de Unix, pero no Linux. Hay alguna ventaja en este enfoque; por ejemplo, en Linux, las interfaces de red podrían aprovechar udev . Pero las ventajas son limitadas, por lo que no se ha hecho.

La mayoría de las aplicaciones relacionadas con la red no se preocupan por las interfaces de red individuales, funcionan a un nivel superior. Por ejemplo, un navegador web quiere hacer conexiones TCP, y un servidor web quiere escuchar conexiones TCP. Para este propósito, lo que sería útil son los dispositivos para protocolos de red de alto nivel, p. Ej.

{ 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

De hecho, ksh y bash proporcionan dicha interfaz para clientes TCP y UDP. En general, sin embargo, las aplicaciones de red son más complejas que las aplicaciones de acceso a archivos. Si bien la mayoría de los intercambios de datos se realizan con llamadas análogas a ready write, establecer la conexión requiere más información que solo un nombre de archivo. Por ejemplo, la escucha de conexiones TCP tiene dos pasos: uno que se realiza cuando el servidor comienza a escuchar y otro que se realiza cada vez que un cliente se conecta. Estos pasos adicionales no encajan bien en la API del archivo, que es la razón principal por la que las redes tienen su propia API.

Otra clase de dispositivos que generalmente no tienen entradas en /devLinux (pero sí en algunas otras variantes de Unix) son los adaptadores de video. En principio, los adaptadores de video simples podrían exponerse como dispositivos framebuffer , que podrían ser dispositivos de bloques hechos de bloques que representan el color de cada píxel. Los adaptadores de video acelerados podrían representarse como dispositivos de caracteres a los cuales las aplicaciones envían comandos. Aquí, el inconveniente de la interfaz del dispositivo es que es lenta: la aplicación de visualización (en la práctica, un servidor X) necesitaría hacer llamadas al núcleo cada vez que se muestre algo. En cambio, lo que sucede es que el servidor X escribe principalmente directamente en la memoria del adaptador de video, porque es más rápido.

— Gilles 'SO- deja de ser malvado'
fuente

2

De hecho, los adaptadores de video acelerados se exportan como chardevs a través de DRI en Linux. Las operaciones de E / S de archivo no son necesariamente read/ writetampoco; puede usar mmappara archivos asignados y acceso directo a la memoria del dispositivo.

— minmaxavg

11

Lo puedes encontrar en el /sys/class/netdirectorio. Es un enlace simbólico a otro archivo /sys/device/../../, a continuación se muestra la salida de mi máquina virtual (kernel 3.10 de Linux). Y puede usar el comando udevadm info <filename>para revisar su atributo

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
fuente

Bienvenido a U&L. Utilice siempre comillas inversas alrededor del código en línea, especialmente si lo usa de <>otra manera que se interpreta como marcado. (es posible que también desee cambiar su nombre para comenzar con una transcripción ASCII, ya que las personas con teclados simples tendrán dificultades para escribir el primer carácter de su nombre en respuesta a cualquier comentario que haga)

— Anthon

9

La forma de "interfaz de nivel de transporte" (TLI) de AT&T / Solaris para hacer redes TCP / IP tiene archivos especiales como "/ dev / tcp" o "/ dev / udp". El programador abre ese archivo especial para obtener un socket de una familia de protocolos apropiada. Creo que es por eso que debe tener "-lnsl" al compilar un programa que usa sockets en Solaris: debajo de todo, es TLI.

— Bruce Ediger
fuente

44

Linux también tiene /dev/tcpy /dev/udp, aunque la mayoría de los núcleos lo tienen deshabilitado.

— bahamat

3

Si bien tradicionalmente Linux no ha sido totalmente compatible con posix, ni mucho menos sigue cualquier tipo de estándares de Open Group (fuera de quizás LSB). Ha habido intentos de portar más funcionalidades de UNIX a Linux.

Glendix es uno de esos proyectos que ofrece un puerto del sistema de archivos virtual / net de Plan9 que le permite hacer exactamente lo que describe.

Plan9 Puerto / sistema de archivos de red a Linux

— Dwight Spencer
fuente