一、问题抛出

 Linux中普通文件、目录、字符设备、块设备、网络设备等都被当做文件来对待。虽然他们的类型不同，但是Linux中提供了统一的操作接口。
 普通文件、目录文件显然非常好理解，因此在本文中，我将用最浅显的语言来带大家理解如何将外设当做文件来看待。

二、如何理解

 一个进程中会有各种各样的文件被打开，操作系统要不要统一管理呢?显然是要的。那么如何管理呢?这就不得不提到 Linux 的设计哲学 —— 先描述，在组织

1. 先描述： 从哲学的高度来说，人是通过属性来认识世界的。例如我一提到 “唱、跳、rap、篮球”，大家想必就知道我在说谁。因此只要描述好对象的属性，我们就可以实现对一个对象的刻画，进而实现管理。Linux是用C语言写的，在C语言中，我们就可以使用结构体来描述对象的所有属性。
2. 在组织： 假设我们已经使用 file结构体来描述一个文件，那么再使用一定的数据结构，我们就可以将所有文件组织起来。Linux系统是使用链表的结构来组织各个文件的关系的
   

 我们再思考这样的一个问题：可以用C语言来模拟实现C++的类吗? 答案是可以的。你可能会质疑说C语言结构体中不能存在成员函数，但是别忘了，结构体中可以包含函数指针，由此就可以模拟出成员函数的效果。

​ 基于这样的认识，我们不难想象，struct file 中一定会包含文件读写的"成员函数"，其伪代码形式如下（fp就像是类中this指针一样）：

 虽然不同设备的读写方式一定都是不一样的（读写不一定都有，没有就提供空函数)，但是都要向file结构体提供自己的读写方式。因此 file 结构体能够以统一的视角来看待所有的设备，我们就可以通过使用 file 结构体来统一管理所有的文件

总结:
 不同外设的底层显然存在差异，但是我们引入一层软件层（虚拟文件系统）屏蔽了底层的差异，提供了相同的操作接口，从而实现统一的管理。

三、Linux源码验证

Linux内核中 struct file 结构体如下：

struct file {
	union {
		struct list_head	fu_list;
		struct rcu_head 	fu_rcuhead;
	} f_u;
	struct path		f_path;
#define f_dentry	f_path.dentry
#define f_vfsmnt	f_path.mnt
	const struct file_operations	*f_op;
	spinlock_t		f_lock;  /* f_ep_links, f_flags, no IRQ */
	atomic_long_t		f_count;
	unsigned int 		f_flags;
	fmode_t			f_mode;
	loff_t			f_pos;
	struct fown_struct	f_owner;
	const struct cred	*f_cred;
	struct file_ra_state	f_ra;
	// 略……
};

 我们观察到其中有 const struct file_operations *f_op成员变量，它就代表着各种操作接口，其中就包含我们之前提到的读写接口（部分内容如下）：

struct file_operations {
	struct module *owner;
	loff_t (*llseek) (struct file *, loff_t, int);
	ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
	ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
	ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
	// 略 ……
};