Hi, On 02/12/2013 12:54 AM, Pete Batard wrote: > On 2013.02.11 14:25, Hans de Goede wrote: >> I've taken a quick look at Nathan's proposal, and I plan to do a >> (personal) libusbx git tree with Nathan's hotplug code merged into it >> sometime this week. > > Cool (as long as it stays personal or explictly flagged as "EXPERIMENTAL > - MAY CHANGE AT ANY TIME", while we get a chance to figure the Windows > stuff). > > By the way, some people (other than me) also have a practical > implementation of a libusb+hotplug API, as per > https://github.com/libusbx/libusbx/issues/9
I know, but I'm operating under the assumption that Nathan will eventually do a libusb release with his code, at which point having API compatibility would be good. And yes I know we don't completely agree on this :) As said we should probably just do the libusbx-1.0.x / libusb-2.x split soon and then I can worry about API + ABI compat, and you can create a nice cleaned up API for 2.x :) > >>>> 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. >> >> Hmm, I don't see anything inherently Posixy in their API proposal, it >> is a straight-forward API where you register a callback, and then have >> that called on events. > > OK, maybe I didn't express myself properly here, but I remember having > some concerns while reading the hotplug proposal discussion that some of > the features that seemed to be taken for granted on the other platforms > may not work quite as well on Windows. > > Personally, the first thing I want out of hotplug from a libusbx/Windows > standpoint is to provide applications with the ability to notify users, > who have just plugged a device, that they may need to install a libusbx > compatible driver before they can access it. This means that hotplug > *must* include driverless device handling on Windows, so that we (or > rather the app developer) has the ability to tell end users: "Hey, I see > you've inserted a device, but I can't communicate with it yet. How about > we try to do something about that?". <adding Nathan to the CC, since he is bound to be interested in this too> Oh, yes I definitely want this, this is a must have feature for spice's usb redirection code, and that is what pays the bills :) I think we can easily do this with Nathan's proposal, currently when registering the callback you specify an event mask your interested in and when the callback gets called you get an event type passed in. Currently the following events are defined: LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED: A device has arrived and is ready to use LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT: A device has left and is no longer available Not the best names ever, I would have called them ADDED / REMOVED, but workable :) We can simply add: LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_ARRIVED LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_LEFT Event types, and generate those in the driverless case, apps which don't know how to deal with these won't include them in their event mask and never see them, where as apps which are interested can request them and differentiate between usable devices, and devices which have (some ?) descriptors filled in but are otherwise not usable. Note: 1) I'm not claiming this is easy from an implementation pov, just that the current API can handle this. 2) AFAIK Mac OS X is actually in more or less a similar situation, it has a call to detach the in kernel driver, but the in kernel driver can refuse, and most do. A solution to this is to install a stub driver instead which does allow detaching, at which point the situation is more or less the same as under Windows. So these event types may be useful for Mac OS X too, although I wonder if it is possible to find out if detaching will work without trying? Maybe libusb's Mac OS X code can contain a list of driver-names for drivers known to fail detach and use that to signal the difference? > > Obviously, that's not much of concern on OS-X and Linux, but on Windows, > at least the last time I tried, driverless hotplug event handling was a > royal PITA. Yes, I, or rather my fellow Spice-team members who are doing the windows support, know all about that. > > And I know others have been expressing a laissez-faire attitude with > regards to driverless on Windows, indicating that we shouldn't bother, > but I'm growing a bit tired, and I'm pretty sure libusbx users too, > about having to starting a lot of the libusbx/Windows troubleshooting > with explaining that something might have to be sorted out in the driver > dept before libusbx can roll. So I'd see not having driverless hotplug > handling on Windows as an important shortcoming of any implementation. Ack. > As such, I'd hate to have to be the guy who has to tell a well thought > through API that maybe it needs to have some provisions for cases where > we may not even be to tell whether a device was plugged or removed, > without going through a a costly re-enumeration - a model that I don't > think is gonna fit too well into Nathan's proposal. Nathan's proposal / code basically consists of: 1) Adding a thread which somehow detects devices coming and going 2) Adding a way to register callbacks to be notified about this I don't see this as a model which will limit in how smart you can be to do as little work as necessary. IOW *if* it is possible to avoid the re-enumeration it should be possible to do so with the proposed API, or so I think. Looking at the spice-gtk code we currently have for dealing with usb-hotplug under windows (which I did not write), what we currently do is create a hidden window, listen for WM_DEVICECHANGE message and when we get those call libusb_get_device_list and compare against what libusb_get_device_list returned on a previous call... IOW yes we do a full re-enumeration on the software side, I would hope that a call to libusb_get_device_list under Windows only involves making a ton of syscalls to get info, and not involves actually talking to the devices, but still it is not pretty ... Hopefully actually having hotplug inside libusb can do better, but even if it does not, this (costly) re-enumeration will only happen on device changes, which should not happen that often. > Or worse, have to be > the guy who has to follow an estbalished API, and "just make it work on > Windows", especially as, judging by the number of people who answered > Nathan's call to get some Windows manpower for libusb, and leaving > modesty aside, it looks like this is what everybody's expecting from me > at this stage... I'll admit I'm sort-off hoping you will do the Windows hotplug code, but I'm not expecting you to make it match whatever API ends up as the final one. The whole reason we're having this discussion now is to get your input, so that if the API will be a poor match, we can fix it before it becomes final. > But, I don't even think the concern I have at the time had to do with > driverless. What I remember is reading one of the posts and thinking "We > may have a problem with this expectation on Windows". Then again, the > implementation got refined many times since then, and I really can't > remember what tickled me at the time, so as I said before, feel free to > consider any reservation from me as baseless for the time being (or pure > FUD, if that's how it looks to you - I accept that the burden of proof > is entirely on me). > > The best I can say at this stage is: I won't know for sure whether > Windows can work with the proposed implementation until we start > actually testing it. Therefore I would very much prefer if caution could > be injected in the "Nah, this'll work just fine on Windows - let's just > run away with that proposal" rhetoric. I completely understand. <snip> >> Then we can try to get them to change the API before it is too late. > > The thing is we have much more to benefit to see them go with their API > and learn from any mistakes they might have made, than try to rush. And > no, that's not from a malicious standpoint of secretly hoping that their > API fails (since it'll sure make things a lot easier for us if that > proposal works across all platforms), but simply because, as with any > new work, there's a non negligible chance that some issues will arise, > and we'll be in a much better position to see them exposed by libusb users. Right, as you say: "it'll sure make things a lot easier for us if that proposal works across all platforms", I understand you don't have a crystalball and all, but if you do think of any concrete / possible problems with the current proposal, now would be the time to speak up :) <snip? >> lets just do a 1.0.15 when *we* are ready, > > Yup. And right now we're not, especially as I think it makes sense to > pick some of the changes from Nathan's repo for 1.0.15. Right, I'll start looking into that soon. <snip> > I was thinking of adding a _RESERVED where they have hotplug, or > anything else we don't plan to carry for the time being. > Unless both ourselves and the libusb guys are very shortsighted (or > decide not to give a damn about users who may not care that much about > forks), it should be quite obvious that it's in both our interests not > to step on each other's toes with regards to caps, especially as doing > so is really a no brainer. And of course _RESERVED can become a full > fledged cap the day we decide to carry it over. > >> But we should then (at-least for the 1.0.x series) coordinate >> with them on this. I'm hereby volunteering to do that coordination. > > No problem with that. I don't see coordination to be that necessary, but > if you want to go ahead, no objection here. I agree coordination is not a big deal, just trying to avoid race conditions where both libusb and libusbx decide to claim CAP number X at more or less the same time, and both do an official release before realizing this. I know the chances of this are very small. But if all it takes to avoid this is one small mail, that is very much worth it, considering the trouble we'll have otherwise. <snip> > Granted, by the looks of it, I'd say Greg is unlikely to want to use > libusbx 2.0 API if he finds that the libusb 1.x one works just fine in > the environments he cares about, regardless of the shortcomings it may > or may not have on Windows, but still, other developers may be put off > by the same API being introduced a few months apart in 2 different major > branches, if there exists incompatibilities between them. I think we all agree that the ideal outcome is to have a single API for all of libusb libusbx-1.0.x and libusbx-2.x. <snip> Regards, Hans ------------------------------------------------------------------------------ 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
