Hi,
On 05/19/2013 04:06 AM, Pete Batard wrote:
> On 2013.05.18 10:41, Hans de Goede wrote:
>> I disagree, just because we cannot have the perfect API, is not a very
>> valid reason to not add support for something, as long as we can do
>> so with a good enough API. To quote Torvalds:
>> "perfect is the enemy of good".
>
> Except we're not trying for perfect here. We're trying to avoid having
> to duplicate/maintain the same thing twice.
>
> Or maybe you misunderstood what I was saying. What I am proposing is not
> introducing BOS/ep_comp in current, but switch to the next API _now_,
> and introduce it there.
I understood that perfectly, I just don't agree.
>
> You proposal would mean maintaining the same API twice. I can't really
> call that a "good" solution especially when the better and easier
> solution is to avoid duplicates.
Correct, I'm willing to pay that price, in order to offer what I
consider useful functionality to 1.x users. A lot of apps will
likely stick with 1.x for a while for various reasons, and
may end up needing bos or ss-endp-comp support.
I know you think that not having that in 1.x would be a compelling
reason for them to move to 2.x. But to me serving our users is
more important then compelling them into making a version switch
they don't want to make yet (ie because that means adding either
ifdef-s, or requiring a version not widely available on all
distros yet).
As said I'm willing to pay the price of having to maintain 2
slightly different API-s for this. And I promise I will maintain
the 1.x API for this for as long as I'm an active libusb
contributor.
>> You make a very valid point here, and since we certainly don't want to
>> be changing the ABI every time we add support for a new BOS descriptor
>> type, we should design our API in such a way that we don't need too
>
> Yeah. That was something I alluded to about a month ago when I posted
> about the BOS/ep_comp implementation I saw in libusb.
>
> Unrolling the BOS was actually one of the few points where I was trying
> to compromise with the libusb API.
>
>> here is a proposal for that:
>>
>> struct libusb_bos_dev_capability_descriptor {
>> uint8_t bLength;
>> uint8_t bDescriptorType;
>> uint8_t bDevCapabilityType;
>> uint8_t dev_capability_data[0];
>> };
>>
>> struct libusb_bos_descriptor {
>> uint8_t bLength;
>> uint8_t bDescriptorType;
>> uint16_t wTotalLength;
>> uint8_t bNumDeviceCaps;
>> struct libusb_bos_dev_capability_descriptor *dev_capability[0];
>> };
>>
>> This will allow libusb_get_bos_descriptor to simply always return all
>> descriptors.
>
> and be closer to the specs, which is always a good idea.
>
>> For known types like the USB 2.0 Extension descriptor we will then
>> offer functions like:
>> int libusb_get_usb_2_0_extension_descriptor(struct
>> libusb_bos_dev_capability_descriptor *bos_dev_cap, struct
>> libusb_usb_2_0_extension_descriptor *usb_2_0_extension);
>
> not exactly sure I like the multiplication of get_bos_whatever (with all
> its limitations, the one good thing the previous proposal has is easy
> access to any of the BOS attributes we unrolled), but I'm not seeing any
> great alternatives that could be future-proof.
That is what I thought too.
> The one thing we may want to consider is that some of these
> sub-descriptors may end up having a version number deciding their length
> and/or format (I don't think any of the current ones do, but we're
> trying to future proof the thing), which I believe is what you allude to
> below:
>
>> Or, if they have nested descriptors:
>> int libusb_get_foo_descriptor(struct
>> libusb_bos_dev_capability_descriptor *bos_dev_cap, struct
>> libusb_foo_descriptor **foo);
>> void libusb_free_foo_descriptor(struct libusb_foo_descriptor *foo);
>
> and which requires to balance each call with a free as you point out.
> But then again, get_desc / free_desc is what we have pretty much for all
> other descriptors already, so it won't be that different from our
> existing model.
>
>> Note the difference in how we handle static-sized versus nested types
>> is following the existing pattern of how we do this with device descriptors
>> vs config descriptors.
>
> If it were up to me, I'd consider that no descriptor is going to be
> static ever. You never know what surprise the future specs might hold.
That is a good point, so lets treat them all as dynamic.
>
>> This also fixes the potential issue you mentioned in this comment:
>>
>> /* The following assumes that only one descriptor of the following
>> * types will ever be provided by the device for each
>> endpoint... */
>
> A limitation of the libusb implementation (not sure if this was in the
> original patch), which I wasn't thrilled about, hence the comment.
>
>> The question really boils down to:
>> 1) Not having ss ep desc support in our current ABI version
>> 2) Doing an ABI breaking release to add it in an API wise better manner
>> and then quickly having todo an other ABI breaking release to fix
>> all our other API issues
>> 3) Having less then ideal, but still very usable ss ep desc support
>> in a manner compatible with our ABI
>>
>> 1) Is not really desirable given how long patches for this have been
>> floating around
>
> Unless we let 1.0 go the way of the dodo, like 0.1 has, and shift our
> development to 2.0/1.1.
Well 0.1 has not gone they way of the dodo by a long shot, having
to maintain it forever has been cleverly dodged by doing a compat-wrapper,
so we don't need to backport bug-fixes all the time.
Which I agree is something we could and probably should do for 1.x too
(once 2.x has reached a certain level of testing / proven stability).
>> 2) This will mean that rather then maintaining one less then ideal API
>> call separately from what it will look in the next ABI breaking release,
>> we end up maintaining 3 (*) complete different ABI branches, and
>> maintaining an entire branch is a lot more work then maintaining one
>> simple function in 2 different forms.
>
> I really don't understand why you think we'd have to maintain 1.0 if we
> bumped API/ABI version tomorrow. Does anyone maintain 0.1 (besides
> compat, which is peanuts and doesn't need a full time maintainer)?
>
2.0 will not be ready tomorrow, I agree it is about time we start a 2.x
but I don't think we should rush it. And then after that there still
will be some time before a 1.x compat wrapper has been written and
proven enough for people to switch.
In the mean time we don't want distro's to back-port random fixes
themselves, because then each distro's libusb becomes its own
special mix of patches, and we will have no idea what mix of
patches a user is running when we get bug-reports.
I've seen this each distro its own special mix of patches thing happen
with many projects where upstream went inactive. If we stop actively
supporting 1.x, this will have the same end-result as distro's
will want to keep using it.
Esp. enterprise distros like SLES and RHEL will not make the jump to a
2.x + compat wrapper for existing releases, which are supported for 10+
years, ie RHEL 6 EOL is currently scheduled for Q4 of 2023 and if past
experiences are any ground for prediction this will likely get
pushed further back.
> The way I see it, when we bump, we drop _ALL_ work on the previous
> version. That doesn't mean people can no longer use it. It just means
> that if they want fixes, they should upgrade. And there we go back into
> the whole "but it's not fathomable to tell developers that they should
> really upgrade to the latest dependencies if they want the latest stuff
> there", which I genuinely cannot understand.
I'm afraid you're not understanding here is caused by us just coming
from a very different perspective, see my RHEL example above. So I think
it is best to just agree to disagree here.
>
>> 3) So by elimination of 1 and 2, 3 gets my vote
>
> You're eliminating 1 & 2 a bit too hastily if you ask me
See above.
> on the false
> pretence that switching version takes time (Hello? Remember when we
> forked about one year ago, and started to release very quickly after
> that? How would version switching be any more complicated?)
When we forked we kept ABI compat, making us a drop in replacement, had
we not done that our adoption rate would have been a lot lower (on the
Linux side at least).
> and that we
> somehow _have_ to devote resources to maintain multiple versions at once.
We do writing a compat wrapper is devoting resources too, it just is
paying the cost upfront, and hopefully cheaper in the long run. I agree
it is likely the right thing to do. But it has a price too.
> Judging by the number of requests we have seen on libusb and libusbx,
> and unlike hp, nobody appears to be missing ep_comp.
People are missing it, and it is causing issues with supporting usb3
isoc devices, see for example:
https://libusb.org/ticket/173
Which we reminds me we need to fix the massive messup wrt our
get_maxpacketsize functions for 2.x too. Another example of how we
should not rush 2.x too much. Start working on it soon, maybe even
today? Yes, rush it? No.
Regards,
Hans
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
