以下内容整理于Linux字符设备驱动剖析，如有侵权请告知删除。

一、应用层的程序

应用程序一般都是open打开设备文件，read、write、ioctl设备文件，最后close设备文件退出。
int main(int argc ,char *argv[])  
{  unsigned char val[1] = 1;  int fd =open("/dev/LED",O_RDWR);//打开设备  write(fd,val,1);//写入设备，这里代表LED全亮  close(fd);//关闭设备  return 0;  
}  

二、/dev目录与文件系统

/dev/NULL和/dev/console是在制作根文件系统的时候静态创建的，其他设备文件都是系统加载根文件系统和各种驱动初始化过程中自动创建的，当然也可以通过命令行手动mknod设备文件。

三、设备文件的创建

（1）/dev目录下的设备文件基本上都是通过mdev来动态创建的。mdev是一个用户态的应用程序，位于busybox工具箱中。其创建过程包括：

驱动初始化或者总线匹配后，会调用驱动的probe接口。该接口会调用device_create(设备类, 设备号, 设备名)，在“/sys/class/设备类”目录生成唯一的设备属性文件（包括设备号和设备名等信息），并且发送uvent事件（KOBJ_ADD和环境变量，如路径等信息）到用户空间（通过socket方式）。
mdev是一个work_thread线程，收到事件后会分析“/sys/class/设备类”的对应文件，最终调用mknod动态来创建设备文件。
设备文件内容主要是设备号（这个设备文件对应的inode，会记录文件的属性是一个设备（其他属性还包括目录，一般文件，符号链接等））。
应用程序open最重要的一步就是（通过文件系统接口）获得该设备文件的内容，即设备号。
（2）如果初始化过程中没有调用device_create接口来创建设备文件，则需要手动通过命令行调用mknod接口来创建设备文件。

（3）mknod接口分析

四、open设备文件

（1）open设备文件，是为了获取（该设备驱动的）file_operations操作集。

该接口集是struct file的成员，open返回file数据结构指针：

struct file   
{  const struct file_operations *f_op;  unsigned int f_flags;//可读，可写等  …  
};

（2）以下是led设备驱动的操作接口。open("/dev/LED",O_RDWR)就是为了获得led_fops。

static const struct file_operations led_fops = {  .owner =THIS_MODULE,  .open =led_open,  .write = led_write,  
};

仔细看应用程序int fd =open("/dev/LED",O_RDWR)，open的返回值是int，并不是file，其实是为了操作系统和安全考虑。
fd位于应用层，而file位于内核层，它们都同属进程相关概念。
在linux中，同一个文件（对应于唯一的inode）可以被不同的进程打开多次，而每次打开都会获得file数据结构。
每个进程都会维护一个已经打开的file数组，fd就是对应file结构的数组下标。因此，file和fd在进程范围内是一一对应的关系。

（3）open接口分析

通过系统调用后对应调用sys_open，其是vfs层的接口Sys_open(/dev/led)

SYSCALL_DEFINE3(open,const char __user *, filename, int, flags, int, mode)
do_sys_open(AT_FDCWD,/dev/tty, flags, mode);
fd = get_unused_fd_flags(flags);
struct file *f = do_filp_open(dfd, tmp, flags, mode, 0);
path_init(dfd, pathname, LOOKUP_PARENT, &nd);//path_init返回时nd->dentry即为搜索路径文件名的起点
link_path_walk(pathname, &nd);//link_path_walk一步步建立打开路径的各个目录的dentry和inode
do_last(&nd, &path, open_flag, acc_mode, mode, pathname);
filp = nameidata_to_filp(nd);//通过inode节点创建file
__dentry_open()
f->f_op =fops_get(inode->i_fop);

在__dentry_open()函数中有

[cpp] view plain copy

if (!open && f->f_op)
open = f->f_op->open;
if (open) {
error = open(inode, f);
if (error)
goto cleanup_all;
}

其中inode->i_fop在mknod的init_special_inode调用中被赋值为def_chr_fops。
open(inode, f)即调用到chrdev_open。其可以看出是字符设备所对应的文件系统接口，我们姑且称其为字符设备文件系统。

[cpp] view plain copy

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

（4）继续分析chrdev_open

Kobj_lookup(cdev_map,inode->i_rdev, &idx)即是通过设备的设备号（inode->i_rdev）在cdev_map中查找设备对应的操作集file_operations。
关于如何查找，我们在理解字符设备驱动如何注册自己的file_operations后再回头来分析这个问题。

五、字符设备驱动的注册

（1）字符设备对应的结构体cdev

[cpp] view plain copy

struct cdev
{
struct kobject kobj; // 每个 cdev 都是一个 kobject
struct module* owner; // 指向实现驱动的模块
const struct file_operations *ops; // 操纵这个字符设备文件的方法
struct list_head list; //对应的字符设备文件的inode->i_devices 的链表头
dev_t dev; // 起始设备编号
unsigned int count; // 设备范围号大小
};

（2）led设备驱动初始化和设备驱动注册

cdev_init是初始化cdev结构体，并将led_fops填入该结构。
cdev_add函数

[cpp] view plain copy

int cdev_add(struct cdev *p, dev_t dev, unsigned count)
{
p->dev = dev;
p->count = count;
return kobj_map(cdev_map, dev, count, NULL, exact_match, exact_lock, p);
}

kobj_map函数
（1）kobj_map函数使用hash散列表来存储cdev数据结构（即存储设备的信息）。
（2）通过（注册设备的主设备号major）来获得cdev_map->probes数组的索引值i（i = major % 255）；
（3）然后把一个类型为struct probe的节点对象加入到probes[i]所管理的链表中；
（4）probes[i]->data即是cdev数据结构，而probes[i]->dev和range代表字符设备号和范围。
（5）其中参数cdev_map的类型如下：

六、再述open设备文件

通过第五步的字符设备的注册过程，应该很容易理解Kobj_lookup查找led_ops的过程（这里不写）。

至此，获得led设备驱动的led_ops。

（1）接着调用file->f_ops->open来调用led_open

该函数中对led用到的GPIO进行ioremap，并设置GPIO方向、上下拉等硬件初始化。

（2）最后chrdev_open一步步返回

最后到do_sys_open函数中的“struct file *f = do_filp_open(dfd, tmp, flags, mode, 0);”返回。
fd_install(fd, f)，是在当前进程中将存有led_ops的file指针填入进程的file数组中，下标是fd。最后将fd返回给用户空间。而用户空间只要传入fd即可找到对应的file数据结构。