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
