Hi Hans, On 19 April 2012 20:21, Hans Petter Selasky <hsela...@c2i.net> wrote: > I haven't followed the discussions on this list for a while. What's new with > libusbx?
Currently, besides some code cleanup and fixes (some of which came from libusb, some of which didn't) we've added a get_version API that returns the current version of the library (which also includes a nano originating from git commits, though gerrit may change that a bit) and we've also added the xusb sample. The roadmap I pointed out details what we would like to have coming next. > What API's are you changing? We're not removing any APIs from the ones currently found in the libusb git repo, and we also aren't going to break/modify any of the existing APIs, at least for the libusbx 1.0 branch. Now, if libusb decides to add a new API which we don't have, whether we integrate as is, slightly differently or not at all will be subject to what makes the most sense to us, since libusb can do the same (take an API we added and reimplement it differently), we cannot guarantee that the APIs are not going to diverge. In fact, since we have a different approach with regards to integration, we kind of expect them to do. But to reiterate, right now, libusbx is a drop-in replacement and the API you used for libusb will work just the same with libusbx. If you have a project that uses libusb today, you can switch to libusbx tomorrow and shouldn't have to change a single line in your code. > How do you plan to add support for FreeBSD 8 and later, which has its own > implementation of the official libusb 1.0 and 0.1. Ideally, since we followed what libusb did recently for OpenBSD and NetBSD, we'd like to have FreeBSD support as well, but I must say I haven't looked at how the FreeBSD backend implementation is different from the other BSDs, and how tricky it might be depending of much of libusb/libusbx core it reuses (if any at all). But with libusbx currently using the same API as libusbx (apart from a few extras), the arrival of libusbx shouldn't change much for the time being in terms of proposing patches for integration. Eventually, as incompatibilities emerge, the FreeBSD implementaion will probably have to decide whether it wants to follow libusb or libusbx for its API. On the libusbx side, we'll be happy to look at any FreeBSD patches aimed at integration (and we're RERO, so getting experimental/non-finalized backend implementations early doesn't scare us). As to 0.1, the current compatibility layer should work just as well with libusbx as it does with libusb. Of course, as we'd rather concentrate on the future 2.0 API, unless there's a lot of demand, we're probably not going to spend a lot of time on 0.1 matters, which is why we left the compatibility layer out of the fork (only libusb-1.0 is forked. libusb-0.1 and libusb-compat aren't). But unless the FreeBSD implementation has a lot of common code for its 0.1 and 1.0 API implementation, I don't think it should be a problem. If you want to provide more details on how you see the FreeBSD integration occurring, and how different it currently is from the libusb/libusbx implementation of the same API (i.e what we'll need to bridge), we can try to take it from here and see what's achievable in libusbx. Regards, /Pete ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
