On 2013.02.10 01:03, Xiaofan Chen wrote: > On Sun, Feb 10, 2013 at 2:15 AM, Kustaa Nyholm > <kustaa.nyh...@planmeca.com> wrote: >> I'm sure many here also watch the libusb-devel list, >> >> perhaps excluding Pete.
I'm still following it, from afar. But from a libusbx perspective, what I'm really interested in is what actually ends up in the libusb git mainline repo, and no matter how much seems to be happening on the side, it sounds like crickets chirping in there... >> They have made some progress in defining the hotplug >> API...what is our standing on this? I think our standing was that we'd start looking into it in 2.x, when we have completed the existing tasks we have lined up for 1.x. I know the milestone says 3.x, but I never got a chance to reorganize the items there the way I see them happening in the future. At this stage, I don't believe that the 2.x branch is going to be as transitional as we said it'd be, so hotplug will most likely go in there, with the other API changes. >> Do we want to have a look at their vision, pick on it, >> or what? >> >> Has anyone actually had a peek? > > I have asked the other admins to take a look at > Nathan's proposal. Hans has given one feedback. > > I think the hotplug API proposed there is not complete > and I am sure Pete will have some different ideas > about the API. libusbx and libusb will probably diverge > on the Hotplug API. That's the way I see it as well. I can't help but feel concerned that once again we have an API that originated straight from POSIX environments, and that hasn't bothered much in trying to at least outline what it's gonna mean for Windows. I kind of remember seeing at least one area where I had to wonder how Windows was going to make the proposed scheme work. Then again, I wasn't following the implementation too closely, and I didn't check against the hotplug code I already have, so maybe it'll be a nonissue. Still it's not like there wasn't an existing hotplug implementation for Windows (or OS-X and Linux for that matter) that libusb could take a look at when they discussed the API proposal... Right now, since 2.x is still some time away, I'm kind in wait and see mode: let libusb finalize their API, and then see how it works out in practice. >> What's our idea when we can get down to doing start >> on the hot plug? Once we kickstart the 2.x branch, which means after we've pushed all the changes and fixes we need for 1.x. I too want hotplug to happen in libusbx as fast as it can, but there's only so much that can happen with limited resources and a fairly full backlog. >> For those who have not followed libusb-devel, Nathan >> seem to report he has picked WinCE and most other >> things from us, except 'the HID crap'. > > I think his pull is not complete. Last I checked (libusb git seems to have connectivity issues right now) I didn't see CE in Nathan's branch. He also didn't seem to pick the stress tests. Also, as far as I'm concerned, I don't see the CE integration entirely finalized in libusbx, as there's some additional cleanup I'd like to apply to make it a bit less intrusive, so I'm not sure why libusb decided to pick CE before it made it into an actual libusbx release. I'm also surprised that libusb is not using hotplug to try to drop the Windows backend altogether, since they don't seem to have much interest for it. Judging by what I saw happening on the libusb mailing list, Windows support seems to be more of a drag to them than anything else, and they could probably move a lot faster with their "ideal" vision if they removed it altogether. Please don't misunderstand what I'm saying: I'm not advocating for libusb to ditch Windows (because along with the removal of HID, that would another dick move as far as users are concerned), just pleasantly surprised (so far) that they haven't jumped on the occasion to do so. But right now, I'm very interested in seeing if libusb can push a 1.0.16 within the next month, so I'd like to delay our upcoming 1.0.15 (or will it be 1.0.17? - see below) for a few more weeks, on account of me still not having had a chance to complete everything I want to see sorted for 1.0.15, as well as for giving us a chance to pick relevant patches from a libusb 1.0.16 release (since they're logically supposed to have an impending release from being in an RC stage -- though of course past history indicates that RC doesn't seem to mean much the same thing in the libusb universe as what it means for other projects). Oh, and with regards to whether our next version will be 1.0.15 or 1.0.17, if libusb wants to start a versioning pissing contest, with their proposed 1.0.9 -> 1.0.16 jump, I think I'm gonna push for libusbx to join in, as I find it rather amusing that a project that is anything but RERO suddenly wants to compete on revision overtaking. > And do not worry, Peter wil sure drag the leg of Nathan > and make sure the next libusb release to be a present > for 2013 Christmas. :-) That's what worries me most right now. From a libusbx perspective, There are some good changes in Nathan's proposal, so I wouldn't mind having libusb releasing their 1.0.16 soon. I'm also thinking we could use the LIBUSB_CAPABILITY thing for HID, since not all platforms have it. We may also extend that for topology, since that's missing from *BSD, and it doesn't look like we're gonna get much help for it there. Then again, I've been in a similar situation to Nathan's, with a lot of development activity occurring into an officially endorsed libusb personal repo, and supposedly enthusiastic support from the libusb maintainer, yet not much of that effort making it to libusb mainline. > That being said, libusbx is a independent project from > libusb. Down the road, the API will diverge and I > support Pete's vision to change the header file and > library name to libusbx to differentiate from libusb > post 2.0 release (at the same time, Hans wanted to > maintain an API compatible 1.x series if that is > possible, see milestone 1.0.16 which is to be compatible > with 2.1 but with no API breakage). Yeah, I'm kind of hoping that after 1.0.15/17/whatever Hans will take over 1.0.x, and I can get going with 2.x. But it looks like both Hans and I are quite busy, so we'll have to see how it works out in practice. Regards, /Pete ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
