On 2012.05.06 04:43, Xiaofan Chen wrote: > Also now that libusbx fork is public, so I think it is not > a problem to expose the original fork mailing list.
Except we are going to be busy enough with reinstating HID, adding topology, setting up gerrit and other stuff, which are all aimed to be completed in under 4 weeks (looks unlikely right now) so, at least as far as I'm concerned, I know I really won't have time to get back into picking up libusb matters that aren't part of our roadmap for at least a few more weeks. This is even more true as you only exposed one side of the argument, and, for the sake of providing a balanced view, if you want to bring it back right now, I will then have to summarize my points yet again, which is time consuming and will delay what is already planned. I would suggest that, if you want to bring up points that are likely to require additional involvement from libusbx members, be it only for discussing them, you should first add them to the roadmap, so that we have an idea of how much extra work we are expected to go into a release. It would also give us an idea of what the target is expected to be for a resolution, and whether it fits well in the global picture. > You can see that Vitali, Segher (mainly on Mac OS X), Travis > and I tend to agree with the filtering proposal. That's not exactly as I saw it. I think Vitali was on the fence - he just didn't want a separate process but was OK with a thread, and Segher's idea of filtering (per VID:PID) is quite different from Travis' idea of filtering (per class GUID), so everyone still seemed to have a different idea of what they want. Doing a filter on VID:PID on init(), 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. But my understanding is that you and Travis intended this as a way to force class GUID filtering into the Windows backend, which is a very different matter. All in all, I very much stand by my position that we should do things in order, with at least some form of hotplug being integrated before we attempt to remodel the enumeration process. Logically, it should reduce the amount of effort, and make things a lot clearer and simpler for everyone. But then again, there's the libusb method of trying to get everything in at once, while not trying to assign priority or trying to figure out how things may relate to one another... > Pete sees this as a bigger part of the > hotplug discussion and proposed to use a dedicated > enumeration process. Others are against this proposal. They were against doing it in a process, which, IMO, is still the best way of doing it to avoid issues in the long run, as it will nicely tie hotplug in, but not against doing it in a thread. And I still haven't see any evidence think anybody has looked into this as much as I did. I also said that I'd try to have a proposal that everybody could review, which, IMO, is miles better than another round of discussions where one can only ever get a partial picture of what someone else has in mind. But I can't submit a proposal without hotplug. Hotplug is really the single most dramatic bottleneck we have at the moment, as it impacts how we're going to implement cross platform events, how we're going to review enum, and other issues such as the recent patch proposal to fix an enum limitation. Thus, I really think we should all be working towards being in a position where we can deal with hotplug, before we attempt to deal with items for which hotplug is likely to change the whole picture altogether. 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
