问题标签 [linux-device-driver]

我有一个可以很好地编译并加载到 linux 内核中的驱动程序。在这个驱动程序中有一些我想从内核文件'fs/readdir.c'中访问的功能。此外，如何测试是否加载了驱动程序？

我需要类似下面的东西。

我在互联网搜索中找到的所有示例都是从用户空间应用程序中完成的。

我正在编写一个内核模块，需要从现有的块设备执行读取。（/开发/东西）。

有谁知道我可以用作参考的任何其他模块？

欢迎任何指点

(Linux.2.6.30)

根据LWN 上2.6 内核系列中的 API 更改列表，.owner该字段struct proc_dir_entry在 2.6.30 内核中被删除。

所以这里有几个问题：

1. 设置这个字段真的有必要或有用吗？
2. 该字段是刚刚移动到其他地方，还是被永久删除？

我问第一个问题是因为虽然LKMPG 在它的许多示例中设置了这个字段，但内核文档中的procfs_example.c从来没有。

我最新的微处理器（飞思卡尔 iMX233）有 8 个硬件覆盖加上内置的 YUV 到 RGB 转换功能。他们通过 v4l2 驱动程序公开了这些功能。v4l2 文档没有正确说明如何使用它。是否有任何可用的教程或任何参考代码可用于学习 v4l2 api？

我正在阅读 LKMPG（请参阅第 4.1.4 节。取消注册设备），我不清楚何时使用这些try_module_get / module_put功能。一些 LKMPG 示例使用它们，有些则没有。

更令人困惑的是，try_module_get在 2.6.24 源代码的 193 个文件中出现了 282 次，但在Linux Device Drivers (LDD3)和Essential Linux Device Drivers中，它们甚至没有出现在一个代码示例中。

我想也许它们与旧register_chrdev接口相关联（在 2.6 中被 cdev 接口取代），但它们只一起出现在同一个文件中 8 次：

那么什么时候适合使用这些功能，它们是否与特定界面或一组环境的使用相关联？

编辑

我从 LKMPG 加载了sched.c示例并尝试了以下实验：

这让我相信内核现在自己做账，gets/puts可能已经过时了。任何人都可以验证这一点吗？

我正在寻找可以从驱动程序、用户空间实用程序或系统调用中进行的内核模式调用，该调用将要求内核查看 PCI 总线并完全重新运行其初始化，或初始化特定的设备。具体来说，我需要 Kernel 识别一个在启动后添加到总线上的设备，然后配置它的地址空间、中断和其他配置参数，最后启用该设备，以便我可以为它加载驱动程序（除非这一切作为驱动程序负载的一部分发生）。

为此，我被困在 2.4.x 系列内核上，目前正在使用 2.4.20，但如果重要，将移至 2.4.37。该发行版是在 ram 磁盘中运行的精简版 Red Hat 7.3，但我可以添加任何需要的工具来使其正常工作（只要它们与 2.4 系列配合得很好）。

如果一些背景有助于澄清我正在尝试做的事情：从冷启动，一旦在 Linux 中，我使用 GPIO 对 FPGA 进行编程。FPGA 的一部分一旦被编程，就实现了一个简单的 PCI 设备。目前，在对 FPGA 进行编程后，我重新启动系统，Linux 会在启动后识别设备并为其加载驱动程序。

而不是需要重新启动，我想简单地要求内核在启动期间执行任何操作以查找 PCI 设备（我将内核配置为自行查找 PCI 设备，而不是向 BIOS 询问该信息，所以 BIOS 不需要知道这个设备（我希望））。

我相信 Linux 能够在编程后但在重新启动之前看到设备，因为scanpci在我编程后会显示设备，就像lspci -H 1. 我只需要一种方法让它进入/proc/pci、配置和启用。

在某些 PCI 硬件的设备驱动程序中，我有一个ioctl调用来等待 PCI 总线上的传入中断。使用wait_queue_head_t，我通过调用 使任务进入睡眠状态schedule()。

然后，该irq_handler函数在 PCI 总线上产生中断时唤醒该任务。一切似乎都正常工作。

我的问题是如何区分schedule()调用返回是因为我的irq_handler函数唤醒它，还是因为已经发送了一些信号？

我是否必须使用函数中的标志自己处理它irq_handler？

我已经实现了一个字符设备，我想问一下这是否正确：

1. 在用户空间中，我有一个带有 2 个指针的结构。

2. 我write将此结构放入我的设备中。

3. 在我write在 char 设备中的函数中，我copy_from_user将此结构放入 kmalloced 空间。

4. 在此之后，我在 KS 并获得了 2 个指向美国的指针，所以我想要copy_from_user每个指针。我可以在copy_from_user使用这个复制的地址之后立即这样做吗？它们指向美国应用程序中的一个数据，该数据调用write函数而不是write函数参数char *buf。

我试图从高端存储设备的 Linux 块驱动程序中获得最大的性能。目前让我有点难过的一个问题是：如果用户任务在一个 CPU 上启动 I/O 操作（读或写），而设备中断发生在另一个 CPU 上，我会在此之前产生大约 80 微秒的延迟任务恢复执行。

我可以对原始块设备使用 O_DIRECT 看到这一点，因此这与页面缓存或文件系统无关。驱动程序用于make_request接收操作，因此它没有请求队列并且不使用任何内核 I/O 调度程序（您必须相信我，这种方式更快）。

我可以向自己证明，在调用bio_endio一个 CPU 和在另一个 CPU 上重新安排任务之间会出现问题。如果任务在同一个 CPU 上，它会很快启动，如果任务在另一个物理 CPU 上，则需要更长的时间——在我当前的测试系统上通常要多 80 微秒（Intel 5520 [NUMA] 芯片组上的 x86_64 ）。

通过将进程和 IRQ cpu 关联设置为相同的物理 CPU，我可以立即将性能翻倍，但这不是一个好的长期解决方案——无论 I/O 来自何处，我都希望能够获得良好的性能。而且我只有一个 IRQ，所以我一次只能将它引导到一个 CPU —— 如果多个线程在多个 CPU 上运行，那就不好了。

我可以在从 Centos 5.4 的 2.6.18 到主线 2.6.32 的内核上看到这个问题。

bio_endio所以问题是：如果我从另一个 CPU调用，为什么用户进程需要更长的时间才能恢复？这是调度程序问题吗？有什么办法可以消除或降低延迟？

我有一个 Linux 设备驱动程序，它连接到理论上可以使用 64 位地址执行 DMA 的设备。我想测试一下这是否真的有效。

有没有一种简单的方法可以强制 Linux 机器不使用物理地址 4G 以下的任何内存？如果内核映像内存不足，则可以；我只是希望能够强制一种情况，即我知道所有动态分配的缓冲区，并且为我分配的任何内核或用户缓冲区都不能以 32 位寻址。这有点蛮力，但会比我能想到的任何其他东西都更全面。

这应该可以帮助我发现 (1) 硬件配置不正确或未加载完整地址（或只是简单损坏）以及 (2) 意外和不必要地使用反弹缓冲区（因为无处可反弹）。

澄清：我正在运行 x86_64，所以我不关心大多数旧的 32 位寻址问题。我只是想测试驱动程序是否可以使用 64 位物理地址与大量缓冲区正确连接。