字符设备架构

chrdevs[]

VFS让APP层可以找到自己想要的驱动。

char_device_struct

static struct char_device_struct {
	struct char_device_struct *next;
	unsigned int major;
	unsigned int baseminor;
	int minorct;
	char name[64];
	struct cdev *cdev;		/* will die */
} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];

CHRDEV_MAJOR_HASH_SIZE=255；最多可以维护的主设备号，主设备号用作该数组的角标。
chrdevs[]数组成员是struct char_device_struct，核心是成员*struct cdev cdev。

struct cdev （需要实现）

struct cdev {
	struct kobject kobj;
	struct module *owner;
	const struct file_operations *ops;
	struct list_head list;
	dev_t dev;
	unsigned int count;
};

每一个字符设备都需要分配一个cdev结构体进行维护；核心成员const struct file_operations *ops 。
cdev是隶属于char_device_struct，隶属于某一个特定的主设备号；不同主设备号下的cdev存在于同一个链表中，由内核中的链表struct list_head list实现。
dev_t dev 　　　　　　 主设备号
unsigned int count 　　次设备号总数

---

const struct file_operations （需要实现）

每一个字符设备外设和对应的驱动不一样，但是对硬件访问的read、write等API是相同。因此需要在该结构体中完成对这些API的填充（注册）。

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 *);
	.....

read、wrote等完成寄存器操作去操作外设。

---

APP层怎么能找到这个驱动？

1、创建文件节点

/*APP创建一个节点*/
/* c字符设备 主设备号237 次设备号0 */
mknod /dev/hello c major minor

2、创建完节点后，会在内核中出现对应inode文件；记录该文件的属性，存放的是不变的信息。
i_rdev代表了主设备号。

struct inode {
......
	dev_t			i_rdev;
	loff_t			i_size;
	struct timespec		i_atime;
	struct timespec		i_mtime;
	struct timespec		i_ctime;
......

3、进程调用

fd = open("/dev/hello",O_RDWR);

Linux下万物皆文件，所以使用open打开节点文件实现访问驱动（硬件）。
open之后会创建file结构体，存放可变的数据。

open、inode与file

当通过mknod /dev/hello c major minor创建建节点时，也会创建inode，内含该设备的很多信息。

struct inode {
	umode_t			i_mode;
	unsigned short		i_opflags;
	kuid_t			i_uid;
	kgid_t			i_gid;
	unsigned int		i_flags;
	......
	dev_t			i_rdev;/* 设备号 */

但当之后使用open之后会获得fd，这时是通过　tast_struct　　 files_struct　　 file　　 inode　线路进行访问（此时为进程状态下的访问）；实际上file是inode的上层结构，且inode是VFS的统一接口。
由inode做地址偏移得到实际文件inode的，依旧保存有设备号等信息；这时根据是否是proc文件等去调用驱动模块。