On Mon, Sep 13, 2021 at 12:29 PM Ryan McClue <re.mcc...@protonmail.com> wrote:
> Currently, I'm listening to NETLINK_KOBJECT_UEVENT messages with the > following code: > > union UeventBuffer { > struct nlmsghdr netlink_header; > char raw[8192]; > }; > int sock = socket(PF_NETLINK, SOCK_RAW | SOCK_NONBLOCK, > NETLINK_KOBJECT_UEVENT); > > struct sockaddr_nl addr = {}; > addr.nl_family = AF_NETLINK; > addr.nl_groups = 1 << 0; > bind(sock, (struct sockaddr *)&addr, sizeof(addr)); > > UeventBuffer buf = {}; > struct iovec iov = {}; > iov.iov_base = &buf; > iov.iov_len = sizeof(buf); > > struct msghdr msg = {}; > struct sockaddr_nl src_addr = {}; > msg.msg_name = &src_addr; > msg.msg_namelen = sizeof(src_addr); > msg.msg_iov = &iov; > msg.msg_iovlen = 1; > > int bytes = recvmsg(sock, &msg, 0); > char *buf_str = buf.raw; > // parse this buf_str ... > > I have a few questions to clarify my understanding and to make this more > robust: > 1. If I add an Xbox One controller, which evtest shows to be > /dev/input/event14 I get a whole host of messages, e.g: > *add@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0* > > *add@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38* > > *add@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/event14* > > *add@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/js0* > *bind@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0* > *add@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4/1-2.4:1.1* > *add@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4/1-2.4:1.2* > *bind@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.4* > *add@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2* > *change@/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2* > Why so many? > It represents the actual device and subsystem layering in Linux – first there's a USB device (on hub 1-2 port 4), then USB interfaces on that device (1.0 to 1.2), then an input-layer device (input38), then two different /dev nodes exposed by it (generic evdev and what I *think* is legacy joydev? Not sure if it's "legacy" or "still current".) They are necessary; for example, the 1st event that informs systemd-udevd about the low-level USB device is what causes the correct device driver module to be loaded in the first place. > Can I filter them to just get the ones ending with /input/inputXX/eventXX? > It seems you're supposed to use BPF filters via SO_ATTACH_FILTER; at least that's what libudev does. > 2. Currently this only picks up input devices. How would I listen to /snd > devices, /hid devices, etc.? I assume some change to nl_groups, however > what should this be and where is this documented? > There's just one group for all events. (If I remember correctly, group 1 has all events straight from the kernel, group 2 is the same events augmented and retransmitted by udev. Normally programs want the latter. Both have the same events and include all devices, though.) > 3. Currently, I'm manually parsing the *buf_str* to extract the command > and device. Are there some supplied macros that parse this information in a > more robust way? (as is the case for RTNETLINK) > Well, systemd supplies a whole libudev library, so I would generally recommend using that – *instead of* manually working with netlink... (Or more recently sd-device, but I don't think libudev is likely to be going *poof* anytime soon, especially if you're looking for compatibility with older systems or eudev-using distros.) Start with udev_monitor_new_from_netlink() and use udev_monitor_filter_add_match_*() to filter by subsystem, devtype, or some arbitrary property, then you'll receive events already parsed. That's 3 lines of code in comparison to your 30. -- Mantas Mikulėnas