¿Por qué es / dev / null un archivo? ¿Por qué no se implementa su función como un programa simple?

Estoy tratando de entender el concepto de archivos especiales en Linux. Sin embargo, tener un archivo especial en /devparece simplemente tonto cuando su función podría implementarse mediante un puñado de líneas en C, que yo sepa.

Además, podría usarlo de la misma manera, es decir, conectarlo en nulllugar de redirigirlo /dev/null. ¿Hay alguna razón específica para tenerlo como archivo? ¿Convertirlo en un archivo no causa muchos otros problemas, como demasiados programas que acceden al mismo archivo?

Además de los beneficios de rendimiento del uso de un dispositivo con caracteres especiales, el beneficio principal es la modularidad . / dev / null puede usarse en casi cualquier contexto donde se espera un archivo, no solo en las tuberías de shell. Considere los programas que aceptan archivos como parámetros de línea de comandos.

# We don't care about log output.
$ frobify --log-file=/dev/null

# We are not interested in the compiled binary, just seeing if there are errors.
$ gcc foo.c -o /dev/null  || echo "foo.c does not compile!".

# Easy way to force an empty list of exceptions.
$ start_firewall --exception_list=/dev/null

Todos estos son casos en los que usar un programa como fuente o sumidero sería extremadamente engorroso. Incluso en el caso de la canalización de shell, stdout y stderr pueden redirigirse a archivos de forma independiente, algo que es difícil de hacer con ejecutables como sumideros:

# Suppress errors, but print output.
$ grep foo * 2>/dev/null

Para ser justos, no es un archivo regular per se; Es un dispositivo especial de caracteres :

$ file /dev/null
/dev/null: character special (3/2)

Funciona como un dispositivo en lugar de como un archivo o programa, lo que significa que es una operación más simple para redirigir la entrada o la salida, ya que se puede adjuntar a cualquier descriptor de archivo, incluida la entrada / salida / error estándar.

Sospecho que el por qué tiene mucho que ver con la visión / diseño que dio forma a Unix (y, en consecuencia, Linux), y las ventajas derivadas de ello.

Sin duda, hay un beneficio de rendimiento no despreciable al no acelerar un proceso adicional, pero creo que hay más: unix temprano tenía una metáfora de "todo es un archivo", que tiene una ventaja no obvia pero elegante si se mira desde una perspectiva del sistema, en lugar de una perspectiva de script de shell.

Digamos que tiene su nullprograma de línea de comandos y /dev/nullel nodo del dispositivo. Desde una perspectiva de script de shell, el foo | nullprograma es realmente útil y conveniente , y foo >/dev/nulltoma un poco más de tiempo para escribir y puede parecer extraño.

Pero aquí hay dos ejercicios:

1. Vamos a implementar el programa nullusando las herramientas Unix existentes y /dev/null- fácil: cat >/dev/null. Hecho.

2. ¿Se puede implementar /dev/nullen términos de null?

Tiene toda la razón en que el código C para descartar la entrada es trivial, por lo que puede que aún no sea obvio por qué es útil tener un archivo virtual disponible para la tarea.

Considere: casi todos los lenguajes de programación ya necesitan trabajar con archivos, descriptores de archivos y rutas de archivos, porque formaron parte del paradigma "todo es un archivo" de Unix desde el principio.

Si todo lo que tiene son programas que escriben en stdout, bueno, al programa no le importa si los redirige a un archivo virtual que traga todas las escrituras, o una tubería a un programa que traga todas las escrituras.

Ahora, si tiene programas que toman rutas de archivos para leer o escribir datos (lo que hace la mayoría de los programas), y desea agregar la funcionalidad de "entrada en blanco" o "descartar esta salida" a esos programas, bueno, /dev/nulleso es gratis.

Tenga en cuenta que la elegancia de esto es que reduce la complejidad del código de todos los programas involucrados: para cada caso de uso común pero especial que su sistema puede proporcionar como un "archivo" con un "nombre de archivo" real, su código puede evitar agregar un comando personalizado Opciones de línea y rutas de código personalizadas para manejar.

La buena ingeniería de software a menudo depende de encontrar metáforas buenas o "naturales" para abstraer algún elemento de un problema de una manera que sea ​​más fácil de pensar pero que sea flexible , para que pueda resolver básicamente el mismo rango de problemas de nivel superior sin tener que dedicar el tiempo y la energía mental a reimplementar soluciones a los mismos problemas de nivel inferior constantemente.

"Todo es un archivo" parece ser una de esas metáforas para acceder a los recursos: se llama opena una ruta determinada en un espacio de nombres jerárquico, se obtiene una referencia (descriptor de archivo) al objeto, y se puede ready write, etc., en los descriptores de archivo. Sus stdin / stdout / stderr también son descriptores de archivos que se abrieron previamente para usted. Sus tuberías son solo archivos y descriptores de archivos, y la redirección de archivos le permite pegar todas estas piezas juntas.

Unix tuvo tanto éxito como en parte debido a lo bien que funcionaron estas abstracciones juntas, y /dev/nullse entiende mejor como parte de ese todo.

PD Vale la pena mirar la versión Unix de "todo es un archivo" y cosas /dev/nullcomo los primeros pasos hacia una generalización más flexible y poderosa de la metáfora que se ha implementado en muchos sistemas que siguieron.

Por ejemplo, en Unix, los objetos especiales como archivos /dev/nulltuvieron que implementarse en el núcleo en sí, pero resulta que es lo suficientemente útil como para exponer la funcionalidad en forma de archivo / carpeta que desde entonces se han creado múltiples sistemas que proporcionan una forma para los programas Para hacer eso.

Uno de los primeros fue el sistema operativo Plan 9, creado por algunas de las mismas personas que crearon Unix. Más tarde, GNU Hurd hizo algo similar con sus "traductores". Mientras tanto, Linux terminó recibiendo FUSE (que ahora también se ha extendido a los otros sistemas convencionales).

Creo que /dev/nulles un dispositivo de caracteres (que se comporta como un archivo ordinario) en lugar de un programa por razones de rendimiento .

Si fuera un programa, sería necesario cargar, iniciar, programar, ejecutar y luego detener y descargar el programa. El programa simple de C que está describiendo, por supuesto, no consumiría muchos recursos, pero creo que hace una diferencia significativa al considerar un gran número (digamos millones) de acciones de redireccionamiento / canalización, ya que las operaciones de gestión de procesos son costosas a gran escala. implican cambios de contexto.

Otra suposición: la conexión a un programa requiere que la memoria sea asignada por el programa receptor (incluso si se descarta directamente después). Entonces, si conecta la herramienta, tiene el doble de consumo de memoria, una vez en el programa de envío y otra vez en el programa de recepción.

Además de "todo es un archivo" y, por lo tanto, la facilidad de uso en todos los lugares en los que se basan la mayoría de las otras respuestas, también hay un problema de rendimiento como menciona @ user5626466.

Para mostrar en la práctica, crearemos un programa simple llamado nullread.c:

#include <unistd.h>
char buf[1024*1024];
int main() {
        while (read(0, buf, sizeof(buf)) > 0);
}

y compilarlo con gcc -O2 -Wall -W nullread.c -o nullread

(Nota: no podemos usar lseek (2) en las tuberías, por lo que la única forma de drenar la tubería es leerla hasta que esté vacía).

% time dd if=/dev/zero bs=1M count=5000 |  ./nullread
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 9,33127 s, 562 MB/s
dd if=/dev/zero bs=1M count=5000  0,06s user 5,66s system 61% cpu 9,340 total
./nullread  0,02s user 3,90s system 41% cpu 9,337 total

mientras que con la /dev/nullredirección de archivos estándar obtenemos velocidades mucho mejores (debido a los hechos mencionados: menos cambio de contexto, el núcleo simplemente ignora los datos en lugar de copiarlos, etc.):

% time dd if=/dev/zero bs=1M count=5000 > /dev/null
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 1,08947 s, 4,8 GB/s
dd if=/dev/zero bs=1M count=5000 > /dev/null  0,01s user 1,08s system 99% cpu 1,094 total

(Esto debería ser un comentario allí, pero es demasiado grande para eso y sería completamente ilegible)

Su pregunta se plantea como si algo se ganara quizás con simplicidad utilizando un programa nulo en lugar de un archivo. Quizás podamos deshacernos de la noción de "archivos mágicos" y, en su lugar, tener simplemente "tuberías normales".

Pero considere, una tubería también es un archivo . Normalmente no tienen nombre, por lo que solo pueden manipularse a través de sus descriptores de archivo.

Considere este ejemplo un tanto artificial:

$ echo -e 'foo\nbar\nbaz' | grep foo
foo

Usando la sustitución del proceso de Bash podemos lograr lo mismo a través de una forma más indirecta:

$ grep foo <(echo -e 'foo\nbar\nbaz')
foo

Reemplace el grepparaecho y podemos ver debajo de las cubiertas:

$ echo foo <(echo -e 'foo\nbar\nbaz')
foo /dev/fd/63

los <(...) construcción simplemente se reemplaza con un nombre de archivo, y grep cree que está abriendo cualquier archivo antiguo, simplemente se llama así /dev/fd/63. Aquí, /dev/fdhay un directorio mágico que crea canalizaciones con nombre para cada descriptor de archivo que posee el archivo que accede a él.

Podríamos hacer que sea menos mágico mkfifohacer una tubería con nombre que aparezca en lstodo, como un archivo ordinario:

$ mkfifo foofifo
$ ls -l foofifo 
prw-rw-r-- 1 indigo indigo 0 Apr 19 22:01 foofifo
$ grep foo foofifo

En otra parte:

$ echo -e 'foo\nbar\nbaz' > foofifo

y he aquí, saldrá grep foo.

Creo que una vez que te das cuenta de que las tuberías y los archivos normales y los archivos especiales como / dev / null son solo archivos, es evidente que implementar un programa nulo es más complejo. El núcleo tiene que manejar las escrituras en un archivo de cualquier manera, pero en el caso de / dev / null, simplemente puede dejar las escrituras en el piso, mientras que con una tubería tiene que transferir los bytes a otro programa, que luego tiene que en realidad leerlos.

Yo diría que hay un problema de seguridad más allá de los paradigmas históricos y el rendimiento. Limitar la cantidad de programas con credenciales de ejecución privilegiadas, por simple que sea, es un principio fundamental de la seguridad del sistema. /dev/nullCiertamente, se requeriría un reemplazo para tener tales privilegios debido al uso por parte de los servicios del sistema. Los marcos de seguridad modernos hacen un excelente trabajo al prevenir exploits, pero no son infalibles. Un dispositivo controlado por el núcleo al que se accede como un archivo es mucho más difícil de explotar.

Como otros ya señalaron, /dev/null es un programa hecho de un puñado de líneas de código. Es solo que estas líneas de código son parte del núcleo.

Para aclararlo, aquí está la implementación de Linux: un dispositivo de caracteres llama a funciones cuando se lee o se escribe en ellas. Escribir en /dev/nullllamadas write_null , mientras lee llamadas read_null , registradas aquí .

Literalmente un puñado de líneas de código: estas funciones no hacen nada. Necesitaría más líneas de código que dedos en sus manos solo si cuenta funciones distintas a leer y escribir.

Espero que también conozcas el / dev / chargen / dev / zero y otros como ellos, incluido / dev / null.

LINUX / UNIX tiene algunos de estos, disponibles para que las personas puedan hacer un buen uso de los MARCOS DE CÓDIGO BIEN ESCRITO.

Chargen está diseñado para generar un patrón de caracteres específico y repetitivo: es bastante rápido y superaría los límites de los dispositivos en serie y ayudaría a depurar los protocolos en serie que se escribieron y fallaron alguna prueba u otra.

Zero está diseñado para llenar un archivo existente o generar una gran cantidad de ceros

/ dev / null es solo otra herramienta con la misma idea en mente.

Todas estas herramientas en su kit de herramientas significan que tiene media oportunidad de hacer que un programa existente haga algo único sin tener en cuenta su (su necesidad específica) como dispositivos o reemplazos de archivos

Establezcamos un concurso para ver quién puede producir el resultado más emocionante dados solo los pocos dispositivos de personajes en su versión de LINUX.