How Uevents Get Triggered in Kernel

how uevents get triggered in kernel

I can't agree with you about polling. uevent is event-based, so there is no polling.

Triggering uevent happened in many cases and I would rather start with figuring out what uevent types are exist?

Little searching and here you go - in include/linux/kobject.h

enum kobject_action {
KOBJ_ADD,
KOBJ_REMOVE,
KOBJ_CHANGE,
KOBJ_MOVE,
KOBJ_ONLINE,
KOBJ_OFFLINE,
KOBJ_MAX
};

So it's

  • Add event
  • Remove event
  • Change event
  • Move event
  • Online event
  • Offline event

KOBJ_MAX is special and marks and of enum.

There are 2 functions that actually sends uevent - kobject_uevent and kobject_uevent_env. These functions are called with on of the actions listed above.

Finally, to answer your questions. There are no predefined cases that will trigger uevent. If you search for calls of kobject_uevent and kobject_uevent_env you will see that it's happens in various callbacks in different unrelated kernel subsystems.

uevent is kernel facility to unify notifications from various unrelated drivers. So I think there are no well known list of things that will trigger uevent.

uevent sent from kernel to user space (udev)

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

     "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/2­2/2­2: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.

  2. 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

  3. 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.

  4. 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

Resources:

  1. lib/kobject_uevent.c
  2. https://www.kernel.org/doc/pending/hotplug.txt - has userspace program that listens for uevents and prints it.
  3. https://bootlin.com/doc/legacy/udev/udev.pdf

Does 802.11 wireless card trigger any event upon data rate change?

TX or RX rate?

It also depends on what kind of driver is used. If the rate control algorithm is implemented in the firmware then likely it's not possible. If the driver uses mac80211 then you can create a monitor interface and use e.g. tcpdump:

% sudo iw phy0 interface add mon0 type monitor
% sudo ifconfig mon0 up
% sudo tcpdump -ni mon0

Then you'll also get quite some information about the PHY for each packet.



Related Topics



Leave a reply



Submit