将大数据从内核传输到用户空间的最佳方法
我必须每秒将几兆字节的数据从 Linux 内核模块传输到用户空间，并且如果我从该模块读取消息，我不想错过该模块的任何消息。 最好的方法是什么？
对此有几种可能的解决方案：命名管道、过程文件和块设备 但我不确定该选择哪一个以及哪一个能够提供最佳性能，因为我是一名内核新手。
目前，我在内核模块中使用环形缓冲区（带自旋锁）来存储消息，如果正在读取 Proc-File，我会将数据从环形缓冲区放入 Proc-File； 在用户端，我有一个程序重复运行 cat /proc/procfile 并显示输出。这个解决方案的问题在于，而不是得到
消息1 信息2 留言3
我看到输出上有
（有时，每几千条消息一次）消息1 留言留言3
I have to transfer several Megabytes of data per second from a Linux-Kernel Module to User-Space, and I don't want miss any message from the Module, if I read from it.
What is the best way to do this?
There are quite few possible solutions for this: Named-Pipes, Proc-File and a Block-Device
But I am not sure which one to choose and which one promises the best performance since I am a Kernel-Newbie.
At the moment I use a Ring-Buffer (with spinlocks) in the Kernel Module to store the messages and if the Proc-File is being read I put data from the Ring-Buffer to the Proc-File;
on the User side I have a program that runs cat /proc/procfile repeatedly and shows the output. The problem with this solutions is that instead of getting
MESSAGE 1
MESSAGE 2
MESSAGE 3
on the output, I see (sometimes, once every few thousand messages)
MESSAGE 1
MESSMESSAGE3
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能想使用中继接口，以前称为relayfs。
请参阅
Documentation/filesystems/relay.txt。从那里：
You probably want to use the relay interface, formerly known as relayfs.
See
Documentation/filesystems/relay.txt.From there:
总是可以实现我所认为的“穷人的系统调用”：创建一个 char 设备，然后使用您想要的任何语义创建一个自定义 ioctl。
在这种情况下，我假设您有一个 ioctl 传入用户空间缓冲区，并从内核中保存的循环缓冲区返回一块数据。
通过仔细使用原子变量和自旋锁，您应该能够保证快速、安全地访问数据，甚至在必要时跨多个线程也是如此。
It would always be possible to implement what I think of as the "poor man's syscall": create a char device and then create a custom ioctl with whatever semantics you want.
In this case I presume you'd have an ioctl that passes in a userspace buffer, and returns a chunk of data from a circular buffer you hold in the kernel.
With careful use of atomic variables and spinlocks, you should be able to guarantee fast, safe access to the data, even across multiple threads if necessary.
我相信字符设备对您来说是一个很好的解决方案。
I believe character device would be good solution for you.
许多方法都可以使用。然而 Netlink 不是其中之一，因为它不是可靠的传输（如 UDP）。字符设备似乎是合适的，尽管您也可以使用 TCP 套接字（参见 nfsd）。
Many methods are usable. Netlink however isn't one of them, because it is not a reliable transport (like UDP). A character device seems in order, though you could also use a TCP socket (cf. nfsd).