Re: [PATCH] libudev: device - add devtype support

[Marcel Holtmann <marcel@holtmann.org>]

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ð89350234e39b868a5e3df71a8f8c036aaae4fd
> 
> 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