On 2012.05.07 00:43, Xiaofan Chen wrote: > So I actually want to get the simple > VID/PID filter done first which you agree in your first reply > that "as Segher's suggest is a no brainer, and, IIRC, we used to > have something similar in the 0.1 API, so I'm fine with that". > > BTW, there is nothing like that in the 0.1 API.
Yes, my bad, what I was thinking of it what we actually have in the 1.0 API (though I could have sworn to have converted 0.1 or -win32 code to 1.0 that also used filtering): http://libusbx.sourceforge.net/api-1.0/group__dev.html#ga11ba48adb896b1492bbd3d0bf7e0f665 Obviously, the reason for adding a VID:PID filter for enum where the aim would obvioulsy be to open a device with said VID:PID, which can be achieved by the above call, may not be that obvious for many users of libusbx. > And I have another idea is to see whether it is possible to > filter using driver attached. OpenBSD/NetBSD anyway only > support ugen driver (similarly for FreeBSD's libusb wrapper > but the kernel there is more intelligent and can expose ugen > along uhid for generic HID device). And it is anyway good > to know the driver assigned and see what its capability of > libusb support as suggested by your comment to the > libusb.org ticket #67. > http://www.libusb.org/ticket/67 Yeah. We've been toying with the idea of adding backend options during init, and providing backend specific info, so this kind of filtering wouldn't be that far off while we're at it. My current concern is whether we need to prioritize looking into all of this, which is what we do whenever we push for an item that isn't part of the roadmap and that isn't a bug, when we're still very slow dealing with the goals we already have established. I'd prefer if all these addons were actually part of the roadmap too, so that we get a clearer picture of: 1. All the various features we actually need to discuss 2. How much of these we may be trying to shoehorn into each release, and, if it turns out we have too much on our hand, how we should spread/prioritize them. > Take note you still go through all the device but do > not try to get all the descriptor information for those > device not of interets. The simple filtering can already help > many people who are complaining about the performance. > So I think it might be able to be achieved before hotplug. Or become completely unnecessary once we have hotplug and a caching thread/process, which will _also_ benefit people who don't want/can't go with filtering in the first place. I'm not saying I'm gonna oppose simple filtering, but I'm always concerned about adding a patch that will only benefit a limited set of people, when a lot more people could benefit from a more final patch, even if delayed, that would render the previous one obsolete as well as require its removal. Any time spent on something that is going to be removed eventually is time wasted, and right now, I'm seeing another proposed patch with a question mark when it comes to eventually being removed because of hotplug... But to come back to what you suggest above: What about the people for whom we also need to solve the caching issue and that aren't gonna use filtering? Are we saying that filtering is the only way, and that anybody who uses libusbx must come prepared to figure out the kind of filter they should apply to their target device beforehand? That's sounds quite restrictive for a library that aims at being generic (we can't assume that people will know the properties of the device they target), so I would very much prefer if a more global solution was looked into, that sorts caching for everyone. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
