我正在学习 Linux 设备驱动程序并且卡在了major, minor 数字上。到目前为止我所拥有的是:
通过文件系统中的名称访问设备。那些名字 被称为特殊文件或设备文件或文件的 inode 系统。
并且每个设备文件都与绑定(bind)到
dev_t
类型中的 MAJOR 和 MINOR 编号相关联。- 这些编号由函数
register_chrdev_region
分配给设备
有些问题还困扰着我...
fops
结构是否链接到文件结构的f_ops
字段 当我们像cdev_init(&c_dev, &fops);
? 这样初始化设备时,设备文件
- 调用
open("/dev/mydev", O_RONLY);
实际上调用了open()
驱动程序的功能。数字出现在这里吗 找到设备驱动程序的实际写入方法,如果是如何? - 数字,主要用于识别设备驱动程序和
次要设备文件。这个数字的实际作用是什么
当我们对设备文件执行
open()
read()
write()
等操作时?
最佳答案
我认为故事应该从你打字时发生的事情开始:
mknod /dev/c83 c 8 3
它将调用 ext2_mknod("/dev", "c83", CHAR, DEV(8, 3)),大多数文件系统将 mknod 实现为 init_special_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;
} else if (S_ISBLK(mode)) {
inode->i_fop = &def_blk_fops;
inode->i_rdev = rdev;
} else if (S_ISFIFO(mode))
inode->i_fop = &def_fifo_fops;
else if (S_ISSOCK(mode))
inode->i_fop = &bad_sock_fops;
else
printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o)\n",
mode);
}
当您最终调用 open("/dev/c83") 时,它将进入函数 def_chr_fops.chrdev_open,它将用您在 cdev_init() 中注册的 fop 替换文件“/dev/c83”的 fop:
int chrdev_open(struct inode * inode, struct file * filp)
{
struct cdev *p;
...
p = inode->i_cdev;
...
filp->f_op = fops_get(p->ops);
...
if (filp->f_op->open) {
lock_kernel();
ret = filp->f_op->open(inode,filp);
unlock_kernel();
}
...
return ret;
}
之后,每一个系统调用,如read/write/close,都直接指向在cdev_init()中注册的函数指针!
所以,对于你的第一个问题:
- 是的,正如您在 chrdev_open() 中看到的那样。
- 是的,因为设备的 fops 与在 cdev_init 中注册的 fops 完全相同
- 在 open() 中起着重要作用,因为 open() 使用对来查找正确的设备驱动程序。但在那之后,其他文件操作,如读/写/关闭(),不再参与,一切都通过 fops 中的函数指针解析在 open()中。
关于linux - 设备驱动程序中主要和次要编号的作用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14583183/