字符设备驱动Open调用过程

使用open函数打开设备文件，到底做了些什么工作？下图中列出了open函数执行的大致过程。

设备文件通常在开机启动时自动创建的，不过，我们仍然可以使用命令mknod来创建一个新的设备文件，命令的基本语法如下：
mknod 设备名 设备类型 主设备号 次设备号

当我们使用上述命令，创建了一个字符设备文件时，实际上就是创建了一个设备节点inode结构体，并且将该设备的设备编号记录在成员i_rdev，将成员i_fop指针指向了def_chr_fops结构体。这就是mknod负责的工作内容，具体代码见如

mknod调用关系

static struct inode *shmem_get_inode(struct super_block *sb, const struct inode *dir,
umode_t mode, dev_t dev, unsigned long flags)
{
inode = new_inode(sb);
if (inode) {
......
switch (mode & S_IFMT) {
default:
inode->i_op = &shmem_special_inode_operations;
 init_special_inode(inode, mode, dev);
 break;
 ......
 }
 } else
 shmem_free_inode(sb);
 return inode;
 }
 void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev)
 {
 inode->i_mode = mode;
 if (S_ISCHR(mode)) {
 inode->i_fop = &def_chr_fops;
 inode->i_rdev = rdev;
 }
 ....
 }

命令mknod最终会调用init_special_inode函数，由于我们创建的是字符设备，因此，会执行第22~23行的代码。这样就完成了上图的内容。

我们使用的open函数在内核中对应的是sys_open函数，sys_open函数又会调用do_sys_open函数。在do_sys_open函数中，首先调用函数get_unused_fd_flags来获取一个未被使用的文件描述符fd，该文件描述符就是我们最终通过open函数得到的值。紧接着，又调用了do_filp_open函数，该函数通过调用函数get_empty_filp得到一个新的file结构体，之后的代码做了许多复杂的工作，如解析文件路径，查找该文件的文件节点inode等，直接来到了函do_dentry_open函数，如下所示。

do_dentry_open函数（位于内核源码/fs/open.c文件）

static int do_dentry_open(struct file *f,
struct inode *inode,
int (*open)(struct inode *, struct file *),
const struct cred *cred)
{
……
f->f_op = fops_get(inode->i_fop);
……
 if (!open)
 open = f->f_op->open;
 if (open) {
 error = open(inode, f);
 if (error)
 goto cleanup_all;
 }
 ……
 }

以上代码中的第7行使用fops_get函数来获取该文件节点inode的成员变量i_fop，在上图中我们使用mknod创建字符设备文件时，将def_chr_fops结构体赋值给了该设备文件inode的i_fop成员。到了这里，我们新建的file结构体的成员f_op就指向了def_chr_fops。

def_chr_fops结构体（位于内核源码/fs/char_dev.c文件）

const struct file_operations def_chr_fops = {
.open = chrdev_open,
.llseek = noop_llseek,
};

最终，会执行def_chr_fops中的open函数，也就是chrdev_open函数，可以理解为一个字符设备的通用初始化函数，根据字符设备的设备号，找到相应的字符设备，从而得到操作该设备的方法，代码实现如下。

chrdev_open函数（位于内核源码/fs/char_dev.c文件）

static int chrdev_open(struct inode *inode, struct file *filp)
{
const struct file_operations *fops;
struct cdev *p;
struct cdev *new = NULL;
int ret = 0;
spin_lock(&cdev_lock);
p = inode->i_cdev;
 if (!p) {
 struct kobject *kobj;
 int idx;
 spin_unlock(&cdev_lock);
 kobj = kobj_lookup(cdev_map, inode->i_rdev, &idx);
 if (!kobj)
 return -ENXIO;
 new = container_of(kobj, struct cdev, kobj);
 spin_lock(&cdev_lock);
 /* Check i_cdev again in case somebody beat us to it while
 we dropped the lock.
*/
 p = inode->i_cdev;
 if (!p) {
 inode->i_cdev = p = new;
 list_add(&inode->i_devices, &p->list);
 new = NULL;
 } else if (!cdev_get(p))
 ret = -ENXIO;
 } else if (!cdev_get(p))
 ret = -ENXIO;
 spin_unlock(&cdev_lock);
 cdev_put(new);
 if (ret)
 return ret;

 ret = -ENXIO;
 fops = fops_get(p->ops);
if (!fops)
 goto out_cdev_put;

 replace_fops(filp, fops);
 if (filp->f_op->open) {
 ret = filp->f_op->open(inode, filp);
 if (ret)
 goto out_cdev_put;
 }

 return 0;

 out_cdev_put:
 cdev_put(p);
 return ret;
 }

在Linux内核中，使用结构体cdev来描述一个字符设备。在以上代码中的第14行，inode->i_rdev中保存了字符设备的设备编号，通过函数kobj_lookup函数便可以找到该设备文件cdev结构体的kobj成员，再通过函数container_of便可以得到该字符设备对应的结构体cdev。函数container_of的作用就是通过一个结构变量中一个成员的地址找到这个结构体变量的首地址。同时，将cdev结构体记录到文件节点inode中的i_cdev，便于下次打开该文件。继续阅读第36~45行代码，我们可以发现，函数chrdev_open最终将该文件结构体file的成员f_op替换成了cdev对应的ops成员，并执行ops结构体中的open函数。

最后，调用上图的fd_install函数，完成文件描述符和文件结构体file的关联，之后我们使用对该文件描述符fd调用read、write函数，最终都会调用file结构体对应的函数，实际上也就是调用cdev结构体中ops结构体内的相关函数