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 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?". 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. 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. 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. 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... 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. > They don't even have the event loop pumping problem we have with the > async API, since libusb will spawn a thread itself for the hotplug > stuff, so API users should always be prepared for the callback to run > from another thread (which one could argue is a downside of their API > design for Linux, since most apps there will simple want a single > select driven event loop), but I don't see this as a problem for > implementing it under Windows. Well, if you looked at the now >2 year old hotplug proposal, you'd see that using a thread to handle hotplug events is exactly what we've been doing in Windows (see windows_hotplug_threaded at [1]), so the threading part is not what's concerning me. Heck, if you remember, I've been advocating to use a separate process for both enumeration and hotplug event handling (which I still see that as the most appropriate solution eventually, precisely because of driverless and polluting bus queries issues)... > They also have seem very simple device filtering in there, but again > nothing which should be a problem under Windows I think, I guess I'll just point out to something I discovered no later than a few days ago, where I ended up doing some hotplug handling for Rufus [2]: If you format a mass storage USB drive as GPT, then remove the partitions, and try to monitor hotplug events, for some weird reason that only MS can explain, and unlike what is the case if you have at least one partition, you're not going to be able to differentiate between arrival or removal of that device. I know, not related to filtering, and who cares about mass storage for libusbx/Windows, but I'm just trying to point that the Windows hotplug model may reserve some bad surprises... > There may be some gotcha's when you start using libwdi to replace the > native windows driver with winusb / libusb0 / libusbk while an app > using the hotplug stuff is open, but that is unrelated to the API, that > is just tricky in general. I think the "libwdi" is extra in there (and is what got Xiaofan confused). Whether libwdi or something else is used to replace the driver doesn't change a thing. And that's part of why I'd like to have driverless sorted, because I think it will naturally help with any "driver swap" handling. > I would appreciate your input on any potential Windows issues with > Nathan's current API proposal here: > http://www.cs.unm.edu/~hjelmn/libusb_hotplug_api_alt4/group__hotplug.html Considering that it took me 6 months to churn through the unexpected CE backend proposal, and this whole hotplug API proposal is another major unexpected change, I'd really like to avoid making any promises at this stages. So, I'll continue sticking to my official line which is that I'm not planning to look into hotplug for Windows before we get 2.0 rolling. > 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. >> 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. > > Eh, no, please lets not go there. Lets just keep doing our own thing > and let them be, other then taking what is useful from them and > integrating that into libusx. And no, their version inflation thing > is not useful :) Ah, where's the fun if we can't even teach libusb a well deserved lesson with regards to trying to fool people in believing they actually release stuff? ;) Then again, we will hopefully get to 2.0 libusbx releases relatively soon... > 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. > Well we already have libusb_has_capability, so we can already start using > that, Yes, I know. That's basically what I was trying to say. > the only challenge will be keeping the enum libusb_capability abi > compat with what "the other side" is doing. 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. > Note I'm not claiming that that is Nathan's hotyplug work is the best way > forward, we may very well want to do something different > But we should seriously consider using it for > libusbx-1.0.x to allow our users to easily switch between the 2. Well, if we're not sure Nathan's hotplug is the best way, why should we take a risk in getting stuck with something that may have a lot of trouble distancing ourselves from afterwards? How about instead making sure that when we introduce hotplug, and unlike what is the case for libusb, we have a solution that we have verified works on all 3 major platforms, and that we can have some confidence in? Or, as you stated above, how about we just do our own thing? ;) The only way I'd like to see us go with the libusb proposal in 1.x is if we slap a big "EXPERIMENTAL - CAN CHANGE AT ANY TIME AND WITHOUT NOTICE - YOU ACCEPT THAT YOU MAY HAVE TO MODIFY YOUR CODE IN THE FUTURE IF YOU USE THIS API" on top of it, so that we can avoid having someone like Greg threatening us with an "I know you're free to break APIs between major versions, but can't you just stick with the current hotplug API and just spend time making Windows work with it? Else I don't think I'll be willing to try the libusbx 2.0 API anytime soon...". 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. And even then, if we end up with out users accepting 2 incompatible hotplug APIs between 1.x and 2.x, it'll be a major drag on our limited resources to ensure that we handle the differences when merging patches, etc. The less extra work we can avoid, the better. > I know how you (Pete) feel about this, so maybe after 1.0.15 it is > time for me to take over the 1.0.x series, and you can then focus on 2.x ? The thing is, I actually wouldn't mind if you took over the 1.0.15 release if you feel like it. From what I've read recently, some maintainers seem to abhor having to do any coding as part of their maintenance tasks, but I'm rather at the opposite end of the spectrum: the less I have to perform "pure" maintenance work and the more I can code, the happier I am. :) And yeah, I'll try to get time to spend on that stress test issue (as well as the CE cleanup, because there shouldn't be that much work to do there) Regards, /Pete PS: I think the reason people are starting libusb/libusbx forks is because they are put off by the (relative) complexity of the Windows backend code. And that is pretty much a direct result of trying to implement an API that was designed from the topdown, which, regardless of how much the people who devised it tried to end up with something that seemed simple and abstracted enough, inevitably had to end up on a collision course with the weird restrictions and idiosyncrasies of Windows... [1] http://git.libusb.org/?p=libusb/libusb-pbatard.git;a=commitdiff;h=20e706f33a6caff186340732fa68ce3f261de1c0;js=1 [2] https://github.com/pbatard/rufus/commit/63e6c02f0275073dc8e92db62c91f138bc0dc428#L3R1376 ------------------------------------------------------------------------------ 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
