[systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages

[Ryan McClue]

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? Can I filter them to just get the ones ending with /input/inputXX/eventXX?
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?
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)

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210913/7b9369ce/attachment.htm>