uevent从内核发送到用户空间(udev)

I knew that udev plays on the linux system and it receives uevents sent from the kernel through netlink socket.

我知道udev在linux系统上运行，它接收内核通过netlink socket发送的uevents。

However, my questions are:

然而,我的问题是:

How kernel sends out the event ? It must be something triggered by adding/removing device and then sends out events to udev. How does kernel do this? (Is there any code example I can find? )

内核是如何发送事件的?它必须是通过添加/删除设备触发的，然后向udev发送事件。内核是如何做到这一点的?(我能找到任何代码示例吗?)
udev receives these uevents only through netlink socket. This is the only way that udev does it. Is this correct?

udev仅通过netlink套接字接收这些uevents。这是udev实现它的唯一方式。这是正确的吗?
When uevent is sent out from the kernel, I knew it can do broadcast. However, Can it do unicast?

当uevent从内核发送出去时，我知道它可以进行广播。但是，它能做单播吗?

Thanks for any feedback.

谢谢你的任何反馈。

1 个解决方案

#1

It sends netlink message called uevent. uevent is just string of some special format that is sent via netlink socket. Example:

它发送名为uevent的netlink消息。uevent只是通过netlink套接字发送的某种特殊格式的字符串。例子:

"add@/class/input/input9/mouse2\0    // message
ACTION=add\0                         // action type
DEVPATH=/class/input/input9/mouse2\0 // path in /sys
SUBSYSTEM=input\0                    // subsystem (class)
SEQNUM=1064\0                        // sequence number
PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/usb2/22/22:1.0\0  // device path in /sys
PHYSDEVBUS=usb\0       // bus
PHYSDEVDRIVER=usbhid\0 // driver
MAJOR=13\0             // major number
MINOR=34\0",           // minor number

Kernel function that actually sends uevent is kobject_uevent_env and it's wrapper kobject_uevent that is called in many places.

实际上发送uevent的内核函数是kobject_uevent_env，它的包装器kobject_uevent在很多地方都被调用。

Yes, udev works by receiving uevents from netlink socket. But there is an option - kernel can call usermode helper. In this case kernel spawns one process per hotplug event, supplying environment variables to each new process describing that particular hotplug event. If you look at kobject_uevent_env you'll see that netlink message is actually #ifdef'ed and default action is to call that usermode helper

是的，udev通过从netlink socket接收uevents来工作。但是有一个选项——内核可以调用usermode helper。在这种情况下，内核为每个热插拔事件生成一个进程，为每个描述该特定热插拔事件的新进程提供环境变量。如果您查看kobject_uevent_env，您将看到netlink消息实际上是#ifdef，默认操作是调用usermode helper
In theory netlink messages can be broadcast, multicast and unicast, but kernel sends broadcast message with netlink_broadcast_filtered call. Anyway that message goes to socket of NETLINK_KOBJECT_UEVENT family. You can see netlink socket creation in uevent_net_init.

理论上，netlink消息可以广播、多播和单播，但是内核用netlink_broadcast_filtered调用发送广播消息。无论如何，该消息将发送到NETLINK_KOBJECT_UEVENT家族的套接字。您可以在uevent_net_init中看到netlink套接字创建。
Answering your comment question. You will not see any send function in kernel. send is a system call - it's interface that kernel provides to userspace, but kernel itself does not use any of syscalls. There is a long chain of function calls (in net/netlink/af_netlink.c and net/core/dev.c) from kobject_uevent_env to final sending that doesn't contain any send - in kernel sending skb (socket buffer) is something like placing buffer in queue and then calling scheduler to deliver that buffer and notify userspace that is waiting on syscall recv

回答你的问题发表评论。在内核中看不到任何发送函数。发送是一个系统调用——它是内核提供给用户空间的接口，但是内核本身不使用任何syscalls。有一个长长的函数调用链(在net/netlink/af_netlink中)。c和net/core/dev.c)从kobject_uevent_env发送到不包含任何发送的最终发送——在内核中，发送skb(套接字缓冲区)类似于将缓冲区放入队列，然后调用调度器来交付缓冲区，并通知正在等待syscall recv的用户空间

Resources:

资源:

lib/kobject_uevent.c
lib / kobject_uevent.c
https://www.kernel.org/doc/pending/hotplug.txt - has userspace program that listens for uevents and prints it.
https://www.kernel.org/doc/pending/hotplug.txt -有一个userspace程序来监听和打印uevents。
http://free-electrons.com/doc/legacy/udev/udev.pdf
http://free-electrons.com/doc/legacy/udev/udev.pdf

#1