Re: [systemd-devel] [libudev] is there a function to filter message from kernel with property and value
Thanks for the suggestion! We will investigate. - Yuan -Original Message- From: Lennart Poettering Sent: Sunday, July 3, 2022 5:20 AM To: Wang, Yuan1 Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [libudev] is there a function to filter message from kernel with property and value On Di, 31.05.22 02:48, Wang, Yuan1 (yuan1.w...@intel.com) wrote: > Hi > > Need your kind help for one question! > > Do libudev have a function that could be used to filter the message with > property from kernel socket? No, because that is not optimizable. i.e. we have no way to filter these missages in kernel. We could filter them in userspace on the library once we have them, but that's not really too useful, since you might as well do that yourself, the library wouldn't be any more efficient. Usually, what you want to do instead is mark devices to filter for with a "tag". Which are short strings that devices can be labelled with. Each device can have zero, one or more tags. You set them via udev rules. These tags can then efficiently be filtered for via the library. This is internally implemented via a Bloom Filter, that is tested via a BPF socket filter, which means the kernel already filters the messages, and userspace is never bothered anymore (well, bloom filters are probabilistic, so userspace has to check for false positives). Anyway, long story short: filtering by properties is not supported because you should not do that, and should use tags instead. Also, libudev is obsolete and does not recieve new additions. Use the sd-device API instead. -- Lennart Poettering, Berlin
Re: [systemd-devel] [libudev] is there a function to filter message from kernel with property and value
On Di, 31.05.22 02:48, Wang, Yuan1 (yuan1.w...@intel.com) wrote: > Hi > > Need your kind help for one question! > > Do libudev have a function that could be used to filter the message with > property from kernel socket? No, because that is not optimizable. i.e. we have no way to filter these missages in kernel. We could filter them in userspace on the library once we have them, but that's not really too useful, since you might as well do that yourself, the library wouldn't be any more efficient. Usually, what you want to do instead is mark devices to filter for with a "tag". Which are short strings that devices can be labelled with. Each device can have zero, one or more tags. You set them via udev rules. These tags can then efficiently be filtered for via the library. This is internally implemented via a Bloom Filter, that is tested via a BPF socket filter, which means the kernel already filters the messages, and userspace is never bothered anymore (well, bloom filters are probabilistic, so userspace has to check for false positives). Anyway, long story short: filtering by properties is not supported because you should not do that, and should use tags instead. Also, libudev is obsolete and does not recieve new additions. Use the sd-device API instead. -- Lennart Poettering, Berlin
[systemd-devel] [libudev] is there a function to filter message from kernel with property and value
Hi Need your kind help for one question! Do libudev have a function that could be used to filter the message with property from kernel socket? I am writing an APPs like "udevadm monitor". I see the function "udev_monitor_filter_add_match_subsystem_devtype()" could filter the devtype for the message. And I see the "udev_monitor_filter_add_match_tag" could filter the tag. (But I don't know how does it work) When I use "udevadm monitor --subsystem-match=pci --env" command, I could see some messages from kernel like below. For example, I only want the messages contains "property=value" like "PCI_ID=8086:4941" could come up from kernel space. Could you please shed a light on this? KERNEL[76915.968785] bind /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/ec21a818-5106-49c3-a6f6-e4cb872df440/pci5106:00/5106:00:00.0 (pci) ACTION=bind DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/ec21a818-5106-49c3-a6f6-e4cb872df440/pci5106:00/5106:00:00.0 SUBSYSTEM=pci DRIVER=4xxxvf PCI_CLASS=B4000 PCI_ID=8086:4941 PCI_SUBSYS_ID=8086: PCI_SLOT_NAME=5106:00:00.0 MODALIAS=pci:v8086d4941sv8086sdbc0Bsc40i00 SEQNUM=5527 UDEV [76915.974190] change /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/ec21a818-5106-49c3-a6f6-e4cb872df440/pci5106:00/5106:00:00.0 (pci) ACTION=change DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/ec21a818-5106-49c3-a6f6-e4cb872df440/pci5106:00/5106:00:00.0 SUBSYSTEM=pci qat_event=restarted accelid=0 DRIVER=4xxxvf PCI_CLASS=B4000 PCI_ID=8086:4941 PCI_SUBSYS_ID=8086: PCI_SLOT_NAME=5106:00:00.0 MODALIAS=pci:v8086d4941sv8086sdbc0Bsc40i00 SEQNUM=5526 USEC_INITIALIZED=7691086 ID_PCI_CLASS_FROM_DATABASE=Processor ID_PCI_SUBCLASS_FROM_DATABASE=Co-processor ID_VENDOR_FROM_DATABASE=Intel Corporation - Yuan
