Linux内核中的netlink套接字与userland中的轮询有何不同？

我怀疑netlink套接字在内核应用程序交互上下文中的功能。正如我所读到的，netlink套接字用于从内核到应用程序的基于事件的通知。此应用程序的优点是无需轮询

但和NetlinkSocket的情况一样，它最终也将进行轮询，以检查是否从内核发送了一些数据。所以我的问题是，netlink套接字的这种功能与文件描述符的轮询有何不同？

---

我参考了netlink，但它说明了如何使用netlink，而不是netlink套接字和轮询之间的区别。

对于应用程序，netlink套接字和其他设备文件的行为基本相似（即调用

poll

和

read

）

---

如果您需要netlink的一个功能（如多播），或者如果您的驱动程序变得更易于实现（内核端API更类似于套接字，并且具有内置缓冲），您可以使用netlink，因为您不必自己编写文件操作。

多播将如何发挥作用？就像内核向应用程序发送多播，或者那些应用程序继续轮询设备文件一样，最终是一样的，不是吗？多播与任何单一端点的接口无关。实际上，我想知道是什么使netlink套接字比轮询更可取。我从平台端检查了UeventObserver.java和uevent.c的代码。这两个文件中都有一个while循环，它会不断检查事件。那么它有多好，为什么内核开发人员更喜欢NetlinkSocket而不是任何其他proc或sysfs文件系统来进行通信呢？感谢您回答这个问题：）。。但还有一件事，在同一个链接中有一段写道“通常，应用程序需要定期轮询内核以获取状态更改，尽管密集轮询的成本很高。Netlink通过允许内核也启动会话优雅地解决了这个问题”，尽管它允许启动会话，最终应用程序将轮询套接字。因此，在这种情况下，我们如何使用netlink套接字跳过密集轮询。对

poll

的调用只是等待。本文中“polling”的意思是定期检查状态。

poll（）

函数调用不同于。很可能许多

read（）

将返回-1；对比度边缘触发与持续读取

I/O

值。您所阅读的内容可能不是指系统调用

poll（）

。