On Sun, Feb 10, 2013 at 11:05 AM, Pete Batard <p...@akeo.ie> wrote: > 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.
I agree with you here. I can go and change 3.0 to 2.2 and 3.1 to 2.3 if you think it is okay. >> 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. It is quite recent, in his libusbx branch of libusb-darwin.git. http://git.libusb.org/?p=libusb/libusb-darwin.git;a=shortlog;h=refs/heads/libusbx;js=1 > 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 tend to believe this is just Nathan's idea. Peter will probably drop it. > 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. Kind of agree with you here. But I think Peter will not likely give up and concede defeat to libusbx any time soon. So he will keep the Windows backend and he even claims to looking the Windows codes. > 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). No problems with delaying 1.0.15. > 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. I am not so sure if this is really Peter's idea. >> 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. We can always pick the good ones from Nathan's tree. > 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. Good idea. That is true. I asked the OpenBSD developer and he told me he has no time for that topology. Even though I have some sympathy for the OpenBSD/NetBSD users but I am not an active users of OpenBSD/NetBSD myself. FreeBSD anyway has its own libusb-1.0 API wrapper and is being well taken care of by HPS. So unlikely the OpenBSD/NetBSD backend will get much improvement unless some of their community users chime in. > 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. I think this time it will be similar case. Peter mentions he is reading the Windows codes and not forget to say something bad about the codes. But in the end, I do not expect him to come out with a Windows hotplug implementation himself. He has many ideas and think many other codes are bad (eg: OpenOCD) yet he in the end just do nothing, partly because of lack of time, and partly because he just likes to talk, like me, but since I can not code so I have to talk more and at least I will carry out some testing, include Nathan's codes. I am not so sure if Peter has even tested Nathan's codes... Read my not-so-nice but at least I-am-sincere comments about Peter and his reply. You can see he never forget to post some bad comments about the Windows backend codes... http://libusb.6.n5.nabble.com/libusb-1-0-16rc2-available-tp5711265p5711315.html >> 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. > I understand that. 2.x will be the main one. If 1.0.x can continue, that will be good. If not, so be it... -- Xiaofan ------------------------------------------------------------------------------ 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
