Hi, On 09/28/2012 02:03 AM, Pete Batard wrote: > I'll start with some comments on distro packagers.
<snip> Most work for distros with multiple ABI/API versions will be in that a parallel installable package for the new API/ABI will count as a new package, needing to go through various distro procedures for new packages, and once in place, there will be 2 (or 3 or 4) libusb library packages to maintain instead of 1. This is all not necessarily disastrous :) But still we should at least try not to burn through ABI/API incompatible releases too soon. I also know of several upstreams for other libs who have done that and they are not popular with distros at all! > Now, with regards to the other matters: > > Great, at last somebody else is proposing some rebranding and moving > away from a potentially conflicting libusb space. I never was against that other then for compatibility reasons, so if we drop compatibility, lets rebrand :) > >>>> "libusbx-2.0\libusbx.h" >>> "include <libusb.h>" > > I think we should to go all the way with our header rebranding, and use > libusbx.h, even as we keep libusb_api_call(). Be it only from a > support's perspective, if someone only sends us code, it may help to > have some evidence that they are actually using libusbx just by looking > at it, and that they has a clear intent to do so. Plus, I think the > libusb guys would also be quite happy not to end up with libusbx users > that got confused by the presence of a libusb.h. Hmm, see below. > Besides, we are a fork. And while we of course want to make it easy for > our users to switch, we also have to make it clear that we are a very > separate entity from libusb. As such, we should request our users to > willingly choose which one they really want to use, be it only with a > one letter change in their header. Proceeding any differently seems very > unhealthy to me, as it still leaves some of the uncertainty I would like > to see us break free from. > > And yeah, this makes our own 1.0 -> 2.0 process (slightly) more > difficult. But then again, the real reason for the above was our > decision not to break clean from libusb when we first released, so it > seems a bit of a catch 22. > >>> But I assume we are going to keep calling all the functions / structs >>> libusb_foo and not libusbx_foo, > > That's the way I see it too. While I'm all for helping our users > understand that they need to choose between fork and original, once > we're past that, the need for code modifications should be as close to > zero as possible. > My main worry here is packages which want to be able to build with both libusb versions. We want to keep the #ifdef magic for them to a minimum, which would be easier with keeping the libusb.h name. > As to going 1.9 with big EXPERIMENTAL notices, I'm also all for it. > Good. > Finally, with regards to figuring out some of hotplug, I'll have to dig > up the 3 phase plan that we kind of talked about previously. In the > meantime, this [1] is one way the initial phase (non event related) of > hotplug addition can be approached. > > Regards, > > /Pete > > [1] > http://git.libusb.org/?p=libusb-pbatard.git;a=blobdiff;f=libusb/libusb.h;h=f5eb81110d7ef9698c6c2b1783b681a5a3fa3a2f;hp=d46c68b4512b15b06a547100d47e638766f82f0c;hb=6cb025b4c853f2c034f72e12b1ab243d9d6e2a59;hpb=f62bae968fc07aff6e7f1e77b70e10010652a0df;js=1 Looks sane. One option would be to give the callback an action argument which is an enum of { added, removed } (for now). And warn in the doc we may extend the enum. I don't know why we would but telling users that they may get other values in the future seems like good future proofing. ### On the topic of 2.0, I've one more addition to the API change list, drop the libusb_kernel_driver_active / libusb_detach_kernel_driver / libusb_attach_kernel_driver functions (to be replaced with libusb_ioctl). I expect to have libusb_ioctl patches within a couple of weeks, and otherwise we could just not have these for the first 1.9.x release .. Regards, Hans ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
