驱动程序中的文件操作 [英] File operations in drivers

问题描述

我试图弄清楚驱动程序中文件操作的工作方式.我知道有几个文件操作，但是用于这些操作的函数带有多个参数，而定义的操作本身没有任何参数.

I was trying to figure out how file operations in drivers work. I know there are several file operations but the functions for these operations are called with several arguments while the operations themselves are defined without any.

所以，如果我有这个-

static const struct file_operations proc_myled_operations = { 
     .open = proc_myled_open, 
     .read = seq_read, 
     .write = proc_myled_write, 
     .llseek = seq_lseek, 
     .release = single_release 
 };

现在，我知道内核级驱动程序只能以文件形式从用户应用程序访问.这是一个嵌入式系统，因此我可以通过写入其内存映射寄存器来打开一些LED.

Now I know that kernel level drivers can only be accessed as files from the user application. This is an embedded system so I have some LEDs that I can turn on by writing to their memory mapped registers.

因此，当我打开一个led时，将执行.write或"proc_myled_write"调用，方法是使用fopen打开此文件，然后使用fputs写入它.但是，如果.write映射为"proc_myled_write，并且此函数具有类似-

So the .write or "proc_myled_write" call will execute when I turn an led on which I can do by opening this file using fopen and then writing to it by using fputs. But if .write is mapped as "proc_myled_write and this function has arguments like so -

static ssize_t proc_myled_write(struct file *file, const char __user * buf, 
size_t count, loff_t * ppos)

参数发生了什么?带有这些参数的上述函数没有函数调用.我已经在几个驱动程序中看到了这一点.我只是用了这个，因为它只是一个简单的例子.文件操作如何映射到这些功能?例如，用户空间中的写入"如何跟踪到驱动程序中的写入?

What happens to the arguments? There is no function call for the above function with those arguments. I've seen this in several drivers. I just used this one because it was a simple example. How are the file operations mapped to these functions? How does the, for example, "write" in user space trace to the write in the driver?

谢谢.

推荐答案

当您说没有使用这些参数的上述函数的函数调用"时，我不确定您的意思.

I'm not exactly sure what you mean when you say "There is no function call for the above function with those arguments."

这些功能的原型在声明中定义用于 struct file_operations 本身.

The prototype for these functions is defined in the declaration for struct file_operations itself.

这是struct声明的前几行:

Here is the first few lines from the struct declaration:

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

虽然在声明中未命名参数，但您可以清楚地看到 write()函数是使用与您在问题中提到的类型匹配的4个参数声明的.

While the arguments are not named in the declaration, you can clearly see that the write() function is declared with 4 parameters matching the types that you mention in your question.

将函数分配给它的适当字段( proc_myled_operations.write = proc_myled_write )时，您只是将指针传递给在模块中声明和定义的写函数.函数本身的指针不需要参数.

When you assign the function to its appropriate field (proc_myled_operations.write = proc_myled_write) you are simply passing a pointer to the write function declared and defined in your module. Pointers to functions themselves do not need parameters.

好吧，所以您真正要问的是:用户空间系统调用最终将如何调用模块中的write函数?"好问题！我建议编辑您的问题，以使将来的读者更清楚.

Ok, so you're question really is: "How does the user space system call eventually call the write function in your module?" Good question! I recommend editing your question to make that clearer for future readers.

好吧，让我们看看我是否可以按照笔迹进行学习.我发现了此文档为我提供了开始的位置在代码中查找 write()系统调用.它非常非常，但是，并不是内核中的所有内容都没有改变！我们从write()系统调用声明开始我们的旅程.="noreferrer"> fs/read_write.c :

Well, let's see if I can follow the paper trail. I discovered this document to give me the starting location to look in the code for the write() system call. It's very very old, but hey, not everything changes in the kernel! We start our journey at the write() system call declaration in fs/read_write.c:

SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
            size_t, count)

它使用文件描述符 fd 来获取注册字符驱动程序时创建的 struct文件.然后，它获取文件中的当前位置并调用 vfs_write() .

It uses the file descriptor fd to get the struct file created when you registered your character driver. Then it gets the current position in the file and calls vfs_write().

ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)

并且在此函数中，请参见下一行:

And it is in this function see the following line:

ret = file->f_op->write(file, buf, count, pos);

有！

为消除对 file-> f_op 类型的任何疑问，我们来看一下

To allay any doubts as to the type of file->f_op, we take a look at the definition of struct file and see the following definition for the f_op field:

    const struct file_operations    *f_op;

因此它必须是注册驱动程序时传递的 struct file_operations .！

So it must be the struct file_operations you passed in when you registered your driver. Phew!

希望所有这些链接都会向您展示如果您感到好奇的话如何跟踪其他系统调用.

Hopefully all of these links will show you how to follow the trail for other system calls if you are curious.

这篇关于驱动程序中的文件操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！