device filtering support

[Pete Batard]

On 2012.02.08 15:54, Hans de Goede wrote:
> 1) A process to cache these is not necessary on Linux, as the kernel has
> all
> these cached and provides them in sysfs. If Mac OS X needs to do the
> caching in libusb,
> I'm fine with solving this cross platform, but would prefer a way to
> disable the "caching daemon"
> under Linux since it is not needed there. If windows is the only one
> where the OS does not
> cache these then it might be best to just solve this with something
> windows specific.

I tend to agree.

But right now I see the "caching daemon" being useful for more than 
caching, to handle hotplug and maintain an enum list that libusbx would 
have no need to rebuild, so that's why I think it might make sense to 
have it cross platform.

But we're nowhere near a final implementation in terms of hotplug, so I 
can't tell for sure if what I anticipate will be accurate.

> 2) When I said "adding such functions to libusb" I was actually talking
> about adding the following
> 2 functions:
> int libusb_get_device_manufacturer_string(libusb_device *dev, char *buf,
> int buf_len);
> int libusb_get_device_product_string(libusb_device *dev, char *buf, int
> buf_len);
>
> Which would first call a platform specific function to get the
> manufacturer / product strings
> from the device without opening it (as the user may not have the rights
> to open the device) and
> if that fails, lookup the vid + pid in usb.ids to return the relevant
> string.

Yes, I understood that. But then why limit our solving to just this 
issue when we can have a more long term cross platform solution to all 
our enumeration woes, including the problem you have?

> So rephrasing my question: What do people think about adding
> the 2 proposed functions to libusb? Good or bad idea?

As long as we don't know where we're headed with hotplug and enum, I can 
only see it as stopgap solution.
We want a solution to that issue, yes. But this is enum related, and 
hotplug is likely to be a game changer for enum, so we may add these 
calls only to find out we might have been able to do something better 
and more generic.

I stand by my position that anything pertaining to enum would better be 
left for after we have sorted hotplug.

Regards,

/Pete