Hi David, > > > > I was playing a little bit with libudev and I actually need the DEVTYPE > > > > from uevent for various tasks. Especially with USB and Bluetooth, the > > > > subsystem value is too generic. > > > > > > > > Attached is a patch that implements udev_device_get_devtype() and also > > > > udev_device_get_parent_with_devtype(). Please double check that I did it > > > > the right way. > > > > > > Looks good. Applied. > > > > one minor thing that came to my mind is that DEVTYPE and subsystem are > > actually kinda coupled. So a DEVTYPE="host" has a different semantic for > > USB than for Bluetooth subsystem for example. Not sure if we actually > > care or just add a udev_device_get_parent_with_subsystem_devtype() > > function to give applications a choice if they wanna care. > > Isn't DEVTYPE in the environment already? If so, just use the new API > added here > > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=f089350234e39b868a5e3df71a8f8c036aaae4fd > > instead of Marcel's patch? the use case here is different. You need udev_device_get_parent... ones if you are receiving your device via a monitor. Using the enumeration API only produces overhead. The other main issue was that DEVTYPE has to be read from the uevent sysfs file like MAJOR and MINOR in some cases. An example where this is useful is for all the USB and SDIO composite devices where you have to apply different policies if they share the same parent. One example is a WiFi/WiMAX combo where the actual physical radio is shared and thus only one can be active at a time. For the kernel these two look like independent device, but in userspace we have to apply certain policies. Otherwise nothing will work. Also the problem with USB is that the parent is most times from DEVTYPE usb_interface and that doesn't help. You have to go all up to usb_device before you know that it is actually the same physical device. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
