【问题标题】:Why does size always = 4096 in Linux character driver read call?为什么 Linux 字符驱动读取调用中的 size 总是 = 4096?
【发布时间】:2013-11-20 22:30:28
【问题描述】:

我一直在研究网络上的 Linux char 驱动程序示例,但遇到了我无法解释的行为。

static ssize_t my_read(struct file *f, char __user *user_buf, size_t cnt, loff_t* off)
{
   printk( KERN_INFO "Read called for %zd bytes\n", cnt );
   return cnt;
}

无论用户空间调用中指定要读取的字节数是多少,该消息始终指示cnt=4096字节(例如。

[11043.021789] Read called for 4096 bytes

但是,用户空间读取调用

retval = fread(_rx_buffer, sizeof(char), 5, file_ptr);
printf( "fread returned %d bytes\n", retval );

用户空间的输出是

fread returned 5 bytes.

my_read 中的 size 值总是 4096 而fread 中的值是 5 怎么办?我知道我缺少一些东西,但不确定是什么......

【问题讨论】:

  • 这是否可以预读到具有页面粒度的中间缓冲区(4096 是 CPU 配置中非常广泛使用的页面大小),或者可能是硬盘的块大小(512 表示较旧,4096 表示较新,多TB 驱动器)?您是否尝试过调用 9345 字节时会发生什么?
  • 看起来是这样的。如果我通过用户空间请求 10、20 或 4096 字节,我会在日志文件中看到“读取调用 4096 字节”。如果我通过用户空间请求 4097 字节,我会在日志文件中看到两个新条目“读取调用 4096 字节”。请求 9345 会导致日志文件中有两个条目,“读取调用了 8192 字节”和“读取调用了 4096 字节”。

标签: c linux linux-kernel linux-device-driver


【解决方案1】:

试试read(2)(在unistd.h),它应该输出5个字符。使用 libc(fread(3)、fwrite(3) 等)时,您使用的是内部 libc 缓冲区,它通常是一个页面的大小(几乎总是 4 kiB)。

我相信,当您第一次调用 fread() 5 个字节时,libc 会执行 4096 个字节的内部 read(),而下面的 fread() 将简单地返回 libc 在与 FILE 关联的缓冲区中已有的字节你使用的结构。直到达到 4096。第 4097 个字节将发出另一个 4096 字节的 read,依此类推。

这也会在您编写时发生,例如在使用printf() 时,这只是fprintf() 和stdout() 作为它的第一个参数。 libc 不会直接调用write(2),而是将你的东西放在它的内部缓冲区中(也是4096字节)。如果你调用它会刷新

fflush(stdout);

您自己,或任何时候它在发送的字节中找到字节 0x0a(ASCII 中的换行符)。

试试看,你会看到:

#include <stdio.h> /* for printf() */
#include <unistd.h> /* for sleep() */

int main(void) {
    printf("the following message won't show up\n");
    printf("hello, world!");
    sleep(3);
    printf("\nuntil now...\n");

    return 0;
}

但是这会起作用(不使用 libc 的缓冲):

#include <stdio.h> /* for printf() */
#include <unistd.h> /* for sleep(), write(), and STDOUT_FILENO */

int main(void) {
    printf("the following message WILL show up\n");
    write(STDOUT_FILENO, "hello!", 6);
    sleep(3);
    printf("see?\n");

    return 0;
}

STDOUT_FILENO 是标准输出 (1) 的默认文件描述符。

每次出现换行符时刷新对于终端用户即时查看消息至关重要,并且对于在 Unix 环境中经常执行的每行处理也很有帮助。

因此,即使 libc 直接使用 read() 和 write() 系统调用来填充和刷新其缓冲区(顺便说一下,C 标准库的 Microsoft 实现必须使用 Windows 的东西,可能是 ReadFile 和 @987654345 @),那些系统调用绝对不知道 libc。当同时使用这两种方法时,这会导致有趣的行为:

#include <stdio.h> /* for printf() */
#include <unistd.h> /* for write() and STDOUT_FILENO */

int main(void) {
    printf("1. first message (flushed now)\n");
    printf("2. second message (without flushing)");
    write(STDOUT_FILENO, "3. third message (flushed now)", 30);
    printf("\n");

    return 0;
}

哪个输出:

1. first message (flushed now)
3. third message (flushed now)2. second message (without flushing)

(第二个之前的第三个!)。

另外,请注意,您可以使用 setvbuf(3) 关闭 libc 的缓冲。示例:

#include <stdio.h> /* for setvbuf() and printf() */
#include <unistd.h> /* for sleep() */

int main(void) {
    setvbuf(stdout, NULL, _IONBF, 0);
    printf("the following message WILL show up\n");
    printf("hello!");
    sleep(3);
    printf("see?\n");

    return 0;
}

我从未尝试过,但我想你可以对 FILE* 执行相同的操作,当 fopen() 输入字符设备并为此禁用 I/O 缓冲时:

FILE* fh = fopen("/dev/my-char-device", "rb");
setvbuf(fh, NULL, _IONBF, 0);

【讨论】:

  • +1 - 但是write 是否保证为printf 刷新libc 缓冲区?我一直认为它直接进入内核系统调用,但我在规范中找不到任何有关行为的信息。
  • write 不知道 libc。我将在我的答案中添加一个示例来说明这一点。
  • 我认为它必须与缓冲有关,但不明白为什么会发生这种情况(更具体地说,如何能够请求特定的字节数)。很好的解释!谢谢。
  • write(0, "hello!", 6); 写入标准输入,而不是标准输出。 STDOUT_FILENO 是 1.
猜你喜欢
  • 1970-01-01
  • 2016-03-28
  • 2019-02-14
  • 1970-01-01
  • 1970-01-01
  • 2023-03-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多