之前从编程角度写过Linux的Pipe和FIFO，主要侧重于使用，附带了简单的原理介绍。（链接如下）

http://my.oschina.net/u/158589/blog/54705

http://my.oschina.net/u/158589/blog/55051

今天在看Understanding The Linux Kernel时，发现自己对Pipe和FIFO的理解稍显不足，这里简单的对其原理做一些补充。主要采用Question & Answer的形式。

1. 为什么要将FIFO和Pipe放在一起讲？他们间的区别是什么？

原因是他们的核心数据结构是一样的，pipe_inode_info，并且，FIFO的读写函数和pipe的读写函数也一致。

关于区别，以下要稍微讲一下。使用上的区别参见本文开头的两篇博文。

核心区别有两点。

第一，fifo出现在系统目录树中，而pipe则在特殊文件系统pipefs中。

第二，fifo是双向通信管道，而pipe是单向的。

2. Pipe和FIFO有对应的disk image吗？有对应的indoe吗？他们属于同一个文件系统吗？

pipe和fifo都没有对应的disk image。

他们都是文件，所以肯定有inode。同时，当创建一个pipe或者fifo时，实际上是创建了一个inode和两个file object.

pipe属于pipefs文件系统，fifo不是。所以他们不属于同一个文件系统。

值得注意的是以下两点：

第一， pipefs这个特殊的文件系统在VFS的目录中是没有的，用户不可见，它是在kernel初始化时进行创建并且挂载到VFS上的。

第二，虽然fifo在VFS的目录树下，但是它并不对应disk上的文件，有点像device文件。其核心的buffer是kernel中的buffer.

3. ls | more背后发生了什么？

step1: shell创建一个pipe（假设其file descriptor是3和4，这样方便讨论）。

step2: shell fork出两个子进程。此时，这两个子进程同继承了父进程的文件描述符，也就是说，他们同样有3和4.

step3: 第一个子进程调用dup2(4, 1)。这就将1（标准输出）的file object关闭了，并且，1这个文件描述符，此时指向了4文件描述符指向的file object，即pipe的写端。子进程关闭3和4。子进程execve(), 执行ls命令。由于execve也是用的同一个文件描述符表，所以此时ls的输出实际上是pipe的写端。

step4: 第二个子进程调用dup2(3, 0)。如上，0（标准输入）的file object关闭，并且，0这个文件描述符，指向了3这个文件描述符指向的file object，即pipe的读端。子进程关闭3和4. 子进程execve(), 执行more命令。此时，more的输入实际上是pipe的读端。

于是，ls的输出就顺利的重定向到more的输入了。

4. Pipe和FIFO使用的多吗？

Pipe就不用说了，shell中经常用到，实际编程中如果遇到重定向或者父子进程通信，pipe也是一个不错的选择。就我目前看到过的代码而言，shell中pipe使用较多，c中pipe也有用到，但明显没有semaphore，socket等普遍。

FIFO的话，说实话，基本没见过。我认为原因是他能做的，socket也一定能做，并且能做的更好。所以FIFO就有点累赘了。另外，从本文开头的两篇链接中，我们可以看到，FIFO的编程有点麻烦，要对读写进行比较精确的控制，防止死锁或者竞争。

就到这里吧。