device filtering support

[Michael Plante]

Pete Batard wrote:
>> Michael Plante wrote:
>> > We've lost the context here.  Please elaborate.  Doing *what* has
broken
>> > libusb?  It sounds like you're describing an effect, no topology, as
the
>> > breakage, but you haven't described the cause very clearly.
>> > **** [CONTEXT RESTORED] ****
>> > Or maybe I missed it in the flood of earlier emails.  I do remember
>> > something related to filtering, but does that have anything whatsoever
>> > to do with process vs thread?  If not, what does that have to do with
>> > the text you quoted and replied to from Xiaofan?
>>
>> Cause is filtering on driver class GUID. For instance, you'd get an enum
>> that will only feed properties of devices that are handled by the K
>> driver. Hubs, proprietary would either not be listed or miss some data
>> that our users may expect libusbx to provide.
>>
>> My understanding of what the libusb-win32 and libusbK current enum
>> process does (I might be wrong) is that it only lists a bunch of devices
>> that meets a set of GUIDs that are known beforehand.


So I'll ask again the question I restored above:  what does this "filtering
breaking libusb" have to do with the process vs thread discussion?
Anything?



>> Then you're misconstruing what I say (or if I said it otherwise, I need
>> to amend it). I want to support as many users as possible as long as
>> their expectations are reasonable.
>>
>> [...non-code-related examples snipped...]
>>
>> Users relying on libusbx bugs or poking inside our internal structure to
>> access data outside of our APIs (I know some of those users)?
>> No way!


It needn't be that drastic.  I'm saying that what worked at one point could
continue to work if you went with the threaded approach because no one can
pull the rug out from under you if you link statically.  That fallback isn't
available at all with the process.  You give us too much credit to say that
someone necessarily has to poke at an internal structure to expose this kind
of flaw, but say for a second that they do -- at least with the statically
linked threaded version end-users can continue to use a version of the
software after the company is long dead and gone.


>> but once we have devised our translation, it's not expected to
>> change that much.


The future is hard to predict.  It only takes getting it wrong once and the
whole thing is shot.  See Vitali's compatibility matrix (if you can find the
text; those messages are hard to read).  You add a row and column to that
N^2 matrix for every time we get it wrong, and there are N*(N-1)/2 test
cases, most of which will involve, by definition, truly ancient code.  Are
you going to want to test against libusb-1.0.10 in 15 years (and yes, I'm
assuming we release in a month or so)?  Maybe we'll have moved on from USB,
but maybe not -- I use RS232 and RS485 extensively, and those aren't exactly
new or fast.


Regards,
Michael