linux中的文件描述符(file descriptor)和文件
linux为了实现一切皆文件的设计哲学，不仅将数据抽象成了文件，也将一切操作和资源抽象成了文件，比如说硬件设备，socket，磁盘，进程，线程等。
这样的设计将系统的所有动作都统一起来，实现了对系统的原子化操作，大大降低了维护和操作的难度，想想看，对于socket，硬件设备，我们只要读读写写文件就能对其进行操作是多么爽的一件事。
文件描述符:
那么在操作这些所谓的文件的时候，我们不可能没操作一次就要找一次名字吧，这样会耗费大量的时间和效率。咱们可以每一个文件操作一个索引，这样，要操作文件的时候，我们直接找到索引就可以对其进行操作了。我们将这个索引叫做文件描述符（file descriptor），简称fd，在系统里面是一个非负的整数。每打开或创建一个文件，内核就会向进程返回一个fd，第一个打开文件是0,第二个是1,依次递增。
我们平时说的命令如./test.sh>res2.log 2>&1就是将标准和错误的输出流重定向到log文件里面，通常情况下系统启动后会自动启动文件描述符号0,1,2，当然，你也可以关闭这几个文件描述符，比如关掉1,然后打开一个文件，那么到时候你使用代码中的printf就不会输出到终端，而是会输入到你打开的文件里面（这样在测试的时候免去了我们在代码里面写log的麻烦）
在python中可以用如下拿到fd，在linux下fd叫做文件描述符，在window下fd叫做句柄，所以这就说明了为啥在官方文档中fileno解释是Return the file descriptor or handle used by the connection.
from multiprocessing import Pipe
rpipe, wpipe = Pipe(duplex=False)
print rpipe.fileno() #这个就得到的是fd
文件：
在linux内核中通常会有个task_struct结构体来维护进程相关的表，叫进程控制块，这个块里面会有指针指向file_struct的结构体，称为文件描述表，文件描述符就是这个表的索引。
而这个file_struct会指向一个file的结构体，一般情况下，进程是没有办法直接访问文件的，只能通过文件描述表里面的文件描述符找到文件。file有几个主要的结构体成员，分别是count，file_operation和dentry（directory entry）。
count：这个是引用计数，像上面的pipe，还有fork，dup等的文件描述符可能会指向同一个file，比如现在有fd1和fd2，他们都指向了同一个文件，那么这个文件的计数就是2,要想关闭这个文件，close（fd1）是不能关掉的，因为这个时候计数为1,只有在计数为0的时候才算完全关闭
file_operation：这个指向的文件操作指针，file_operation里面包含了对文件操作的内核函数指针，他指向内核操作函数，比如说read，write，release，open，当然，不同的文件file_opertions有不同的操作，像读取字符设备的文件操作肯定不会和读取正常文件的一样，他们不是读取磁盘，而是读取硬件设备
dentry：目录项，一个指向带有文件路径的dentry结构体指针，我们在操作文件时，一定要知道他的路径，才能进行操作。为了减少读盘次数,内核缓存了目录的树状结构,称为dentry cache,其中每个节点是一 个dentry结构体,只要沿着路径各部分的dentry搜索即可。
现在看下dentry这个结构体指向了什么？
dentry指向了inode，inode是一个包含所有者、文件大小、文件类型和权限位，创建、修改和更新时间等的结构体，保存着从磁盘inode读上来的信息。里面还有两个重要的成员：
分别是inode_opertions和super_block
inode_opertions：是描述文件能进行哪些操作的结构体，他指向了文件操作的内核函数，比如说rm，mkdir，mv等，
super_block：保存着从磁盘分区的超级块读上来的信息，像文件系统类型（比如说是ext2，ext3等），块大小，不同的文件类型，底层的实现是不同的。当然，super_block还有s_root个成员指向了dentry，因为他需要知道文件的根目录被mount 到哪里
file 、dentry、inode 、super_block这几个结构体组成了VFS的核心概念