Siento curiosidad, pero ¿por qué las interfaces de red no están en /dev?
¿Hay algún otro tipo de dispositivo que no esté representado como un nodo en /dev?
Respuesta aceptada:
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 personajes. Para operaciones que no son de lectura y escritura (como el control de flujo en una línea serie), el dispositivo proporciona comandos ad-hoc llamados ioctl.
Algunos dispositivos son muy parecidos a los archivos normales:están hechos de 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 denominan 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 read y write , sería incómodo:presumiblemente cada llamada a write enviaría un paquete, y cada llamada a read recibiría un paquete (y si el búfer es demasiado pequeño para que quepa el paquete, el paquete se perdería).
Las interfaces de red podrían existir como dispositivos que proporcionan solo ioctl . De hecho, esto es lo que hacen algunas variantes de Unix, pero no Linux. Hay algunas ventajas 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 dispositivos para protocolos de red de alto nivel, por ejemplo.
{ echo $'GET http://www.google.com/ HTTP/1.0r';
echo $'Host: www.google.comr';
echo $'r' >&0; cat; } <>/dev/tcp/www.google.com/80
De hecho, ksh y bash proporcionan una interfaz de este tipo para clientes TCP y UDP. Sin embargo, en general, 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 read y write , establecer la conexión requiere más información que solo un nombre de archivo. Por ejemplo, la escucha de conexiones TCP requiere dos pasos:uno que se realiza cuando el servidor comienza a escuchar y otro que se realiza cada vez que se conecta un cliente. Estos pasos adicionales no se ajustan bien a la API de archivos, que es la razón principal por la que las redes tienen su propia API.
Otra clase de dispositivos que normalmente no tiene entradas en /dev en Linux (pero lo hace en algunas otras variantes de Unix) son los adaptadores de video. En principio, los adaptadores de video simples podrían exponerse como dispositivos de memoria intermedia de cuadros, que podrían ser dispositivos de bloque 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 que 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 realizar llamadas al kernel siempre que muestre algo. Lo que sucede en cambio es que el servidor X principalmente escribe directamente en la memoria del adaptador de video, porque es más rápido.