10.2手动推导linux中file, cdev, inode之间的关系
是时候可以手动推导一下linux里面基类父类和子类的关系了
代码放最后把
简单说明版
详细流程
第一步注册驱动
cdev结构体能看做是一个基类,那么链表里面都是字符设备驱动的cdev连载一起,啥串口,lcd的,通过cdev->list_head连接
那cdev结构体里有主次设备号
第一步 使用register_chrdev 在内核创建了新的cdev基类,同时把驱动的file_operation和主次设备号保存在cdev中
此时把cdev放入整体的链表中 : 链表里面都是字符设备驱动的cdev连载一起,啥串口,lcd的
我们的驱动中:
register_chrdev(CHRDEVBASE_MAJOR, CHRDEVBASE_NAME, &chrdevbase_fops);
struct cdev *cdev;//创造了cdev
cdev = cdev_alloc();
cdev->owner = fops->owner;
cdev->ops = fops;//cdev记录下f_op
kobject_set_name(&cdev->kobj, "%s", name); //给cdev的kobj赋值名字,也就是传入的名字
cdev_add(cdev, MKDEV(cd->major, baseminor), count);//cdev加入cdev链表
cdev->dev = dev; //cdev保存主次设备号
cdev->count = count;//cdev保存个设备的个数
kobj_map(cdev_map, dev, count, NULL, //把这个新的dev注册进 kobj_map类型的表cdev_map中,map后续还能再升入一下
exact_match, exact_lock, p); //cdev_map中就有了我们的cdev
struct probe *p;
p = kmalloc_array(n, sizeof(struct probe), GFP_KERNEL); //创建新的probe来保存cdev
p->owner = module;
p->dev = dev;
p->data = data;//cdev赋值成功
kobj_map类型 起始就是包含了一堆probe 也能叫一个probe链表
一个porbe指向另一个probe,
struct kobj_map {
struct probe {
struct probe *next;
dev_t dev;
unsigned long range;
struct module *owner;
kobj_probe_t *get;
int (*lock)(dev_t, void *);
void *data;//就保存了上面的cdev指针,这样在这个map中,cedv就连在一起了
} *probes[255];
struct mutex *lock;
};
第二步创建用户空间能看见的文件,也就是初始化inode节点
inode 对象:描述文件系统中的某个文件,元数据(权限,类型是否为字符设备文件这种.创建时间)
也能理解为ls -l出来的信息
crw–w---- 1 root tty 4, 1 10月 3 23:09 tty1
struct inode {
umode_t i_mode;//模式,如ls-l 出来的 crwx-rx,能区分字符设备和普通文件
kuid_t i_uid;
kgid_t i_gid;
dev_t i_rdev;//如果文件时字符设备,inode里面就有设备号,//如上面的 4 1
const struct file_operations *i_fop;
}
这里图上有两种办法1 驱动初始化后,使用mknode 手动创建一个设备节点
mknode 需要带主次设备号 是为了构造一个inode节点
创建字符设备最后会调用到init_spectial_inode()
fs/inode.c
void init_special_inode(struct inode *inode, umode_t mode, dev_t rdev);//传入了inode节点,但是为字符设备,要继续构造
inode->i_mode = mode;
if (S_ISCHR(mode)) //因为是字符设备 crw--w---- 的c
inode->i_fop = &def_chr_fops;//对这个inode节点的fop赋值默认的char_fop
.open = chrdev_open,
inode->i_rdev = rdev;
另一个是cdev_add的时候使用kobj_add这些进行增加inode节点,后面找个地方细聊kobj基类,这次没看见kobj_add等函数
这一步就是为了构造出 /dev/led这个文件
第三步应用程序打开文件,第四部关联驱动的file_operation
进程打开文件 内核空间的vfs层就会生成一个struct file 对象
struct file{
struct path f_path; //文件的路径
const struct file_operations *f_op;//f_op!!!
struct inode *f_inode; //还偷偷藏了inode
unsigned int f_flags;//标志
fmode_t f_mode;//模式
loff_t f_pos;//偏移
void *private_data;//万能指针
}
同时把这个file结构体放在 fd_table中,每个file结构体对应了这个fd_table索引号,成功后返回这个索引号
此时应用空间调用fd = open(“dev/led”, O_RDWR(标志),0666(模式)); 返回来的fd数值,也就是这个应用程序在vfs空间中对应的fd值
通过 fd_table保存了该进程打开的所有文件
应用程序:
fd = open("dev/led", O_RDWR(标志),0666(模式));
调用到glibc的open() 触发系统调用 产生0x80中断 进入内核层
vfs层:open.c
SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)
上面这个系统调用的宏定义刚好就是说,建了一个系统调用的函数叫sys_open同时还传来三个参
这不就对应上了嘛
do_sys_open(AT_FDCWD, filename, flags, mode);
fd = get_unused_fd_flags(flags);//找一个没有用过的fd给刚打开的文件进行分配fd
struct file *f = do_filp_open(dfd, tmp, &op);//创建了一个file结构体指针
do_file_open()
//pathname一层一层解析文件路径，可参考上次写的文件系统分析
// 最后得到要打开文件的dentry和vfsmount，保存到结构体struct path中，
// 而结构体struct path保存在struct nameidata nd变量中，nd变量也是path_openat的入参
set_nameidata(&nd, dfd, pathname);
// 用于根据nd寻找文件节点，并打开该文件注册的open函数
filp = path_openat(&nd, op, flags | LOOKUP_RCU);
//初始化file
file = alloc_empty_file(op->open_flag, current_cred());//创建一个file
do_last(nd, file, op)) > 0
error = lookup_open(nd, &path, file, op, got_write);//终于寻找你的open了
dentry_open(const struct path *path, int flags,const struct cred *cred)
vfs_open(path, f);
do_dentry_open(struct file *f, struct inode *inode,int (*open)(struct inode *, struct file *))
f->f_op = fops_get(inode->i_fop);//获取inode保存的fop给file的fop
open = f->f_op->open;
open(inode, f);//执行open了,这里也看得出来入参为啥是inode节点和file文件了
.open = chrdev_open,//这里还有点复杂,反正最后调用了inoded的fop->open,也就是char_dev.c 的open,也是第二步赋值过来的open
chrdev_open(struct inode *inode, struct file *filp)
kobj = kobj_lookup(cdev_map, inode->i_rdev, &idx);//从cdev链表中,找到了kobj,关系为 kobj_map->data(cdev)->kobj
cdev *new = container_of(kobj, struct cdev, kobj);//顺带就把驱动注册的cdev找出来了
inode->i_cdev = p = new;//同时还把inode节点里cdev一起赋值,相当于inode也知道驱动的cdev
fops = fops_get(p->ops);//拿到了驱动的fops
replace_fops(filp, fops);//替换file的fops
ret = filp->f_op->open(inode, filp);//执行驱动中的fop->open函数
//进入我们的驱动里.传来的inode是这个模块的ionde,file是进程打开的这个file
int chrdevbase_open(struct inode *inode, struct file *filp)
fd_install(fd, f);//关联file文件和这个fd,那我我们进程的数fd_arry中就把这个文件记录了,也把fop_改了
第五步,执行其他的write等函数
应用执行了ioctrl(fd,cmd,arg);
调用glibc的ioctrl
系统调用
0x80中断
进入内核:
VFS层 fs/ioctrl.c
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg);
ksys_ioctl(fd, cmd, arg);
struct fd f = fdget(fd);//根据应用层传递的fd编号,在数组中找到file结构体
do_vfs_ioctl(f.file, fd, cmd, arg);//传入file结构体,和对应的指令
//从file中取出inode节点
//file->dentry->inode
struct inode *inode = file_inode(filp);
if (S_ISREG(inode->i_mode)) //i_noded文件类型,如果是普通文件,S_isreg regular常规的
error = file_ioctl(filp, cmd, arg);
else //那就是字符文件了
error = vfs_ioctl(filp, cmd, arg);
error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
//因为file的operation在open的时候被改成我们的驱动里的了
static struct file_operations chrdevbase_fops = {
unlocked_ioctl= ioctl,
}//现在就到我们驱动内部
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
代码块
driver
#include