Cómo funcionan las tuberías en Linux

He estado leyendo sobre cómo se implementan las canalizaciones en el kernel de Linux y quería validar mi comprensión. Si soy incorrecto, se seleccionará la respuesta con la explicación correcta.

• Linux tiene un VFS llamado pipefs que está montado en el kernel (no en el espacio del usuario)
• pipefs tiene un súper bloque único y está montado en su propia raíz ( pipe:), junto a/
• pipefs no se puede ver directamente a diferencia de la mayoría de los sistemas de archivos
• La entrada a pipefs es a través de pipe(2)syscall
• La pipe(2)llamada al sistema utilizada por los shells para canalizar con el |operador (o manualmente desde cualquier otro proceso) crea un nuevo archivo en pipefs que se comporta más o menos como un archivo normal
• El archivo en el lado izquierdo del operador de tubería se stdoutredirige al archivo temporal creado en pipefs
• El archivo en el lado derecho del operador de tubería tiene su stdinconjunto en el archivo en pipefs
• pipefs se almacena en la memoria y, a través de la magia del kernel, no se debe paginar

¿Es esta explicación de cómo funcionan las tuberías (p ls -la | less. Ej. ) Bastante correcta?

Una cosa que no entiendo es cómo algo como bash establecería un proceso ' stdino stdoutal descriptor de archivo devuelto por pipe(2). Todavía no he podido encontrar nada al respecto.

Su análisis hasta ahora es generalmente correcto. La forma en que un shell puede establecer el stdin de un proceso en un descriptor de tubería podría ser (pseudocódigo):

pipe(p) // create a new pipe with two handles p[0] and p[1]
fork() // spawn a child process
    close(p[0]) // close the write end of the pipe in the child
    dup2(p[1], 0) // duplicate the pipe descriptor on top of fd 0 (stdin)
    close(p[1]) // close the other pipe descriptor
    exec() // run a new process with the new descriptors in place