On 2013.05.17 14:43, Hans de Goede wrote:
> With that said, I would have liked the new descriptor structures to
> match, so that they can add
> our version if the API, while keeping their own.
Yeah, that's something I considered too. I've actually been 50/50 on
keeping their not to great designations, but ultimately went with trying
to keep close to the specs.
> so my conclusion is bad luck for the FreeBSD libusb people. And if any
> FreeBSD people are
> reading along: Next time please coordinate API changes, and post API
> proposals for review
> on the libusb[x]-devel list!
Seconded.
> If we were to design this from scratch I would completely agree. But
> we're not and we have
> to maintain ABI and API compatibility, so I've to strongly NACK this
> part of your patch:
>
> @@ -531,6 +585,9 @@ struct libusb_endpoint_descriptor {
> /** For audio devices only: the address if the synch endpoint */
> uint8_t bSynchAddress;
>
> + /** SuperSpeed Endpoint Companion descriptor */
> + struct libusb_ss_endpoint_companion_descriptor
> *ss_endpoint_companion;
> +
> /** Extra descriptors. If libusbx encounters unknown endpoint
> descripto
> * it will store them here, should you wish to parse them. */
> const unsigned char *extra;
>
> Put this on your things to cleanup for libusb-2.x list, because we are
> simply NOT going
> to make this change in libusb[x]-1.x.y
Well, if 1.x.y is out of the equation, then I will strongly vote for not
adding BOS and EP companions in 1.x at all.
While I recognize that introducing the extra desc in 1.0 may not be for
the best (or more exactly, that the world is not quite yet ready for
something like that just yet) you have to consider the logical extension
of what you're advocating: Since we unwrap our choice selection of BOS
descriptors, then we're also going to have to break our API again next
time the USB committee introduces a new one there. Say there's a new BOS
for 10 Gbps speed tomorrow, or that suddenly wireless USB becomes real
popular (fat chance... I know!), and we want to add these new
descriptors, what do we do then? Do we go 2.0->3.0 since we've gone
1.0->2.0 when we introduced ep_comp in our descriptors? Heck what if we
already had 2.0 out, but without ep_comp. Should we go 3.0 right there,
and then 4.0 when we want to add additional BOSes?
Now, if you tell me that, no, we shouldn't really change the major
there, and that updating the minor would do, then I'm going to touch
what I am really after here:
Why the heck do "we" seem so hell bent against simply introducing 1.1
for this and the other stuff, and then declaring that 1.1 is where
libusbx happens now.
This is even more true as, with it being a game changer, and even if it
doesn't break the API, hp's logical place is in 1.1, not 1.0. So here we
are, with a golden opportunity to sort everything that's not
experimental and that we really oughta sort, such as USB 3.0, hp,
MaxPower, ctx removal and probably a couple other stuff, but we're not
going to take it because you say that 1.x is off limits? Why?
What can possibly be the reason that makes you not to want to break from
1.0 ever, rather than, like every other library seems to do out there,
bump the micro once in a while, and let the previous version die a slow
yet deserved death, with thanks for the ride.
No matter how I look at it, switching our development focus to an
improved 1.1 is really the best logical solution here. I would go
further, with saying that if we are afraid of embracing such a change,
then there's something quite wrong with our development model. Yeah,
this means another libusb in /lib, and developer having to make a
choice. Big deal.
As you may guess, I'm starting to have my fill with this let's not
evolve the API outside of major, _EVER_, policy. We're developers. At
which point did we take a wrong turn and become so adverse to evolution
and change?
So, like every other library in existence has been doing, and after
years of loyal service, let's fix our shit in 1.1, declare it as the new
camino real, and cease to pretend that requiring app developers to spend
a _minimal_ amount of time to upgrade, _if_ and when they choose so, is
the end of the world, especially when, if not upgrading stuff, ever is
what really floats their boat, they should also be fine with us no
longer upgrading 1.0. Or how's that not fair?
> Instead I suggest we add a:
>
> int LIBUSB_CALL libusb_get_ss_endpoint_companion_descriptor(struct
> libusb_endpoint_descriptor *endpoint_descriptor, struct
> libusb_ss_endpoint_companion_descriptor **ss_endpoint_companion)
Strongly against (even as this is more or less what I had in my patch
for 1 year ago). Supporting and maintaining APIs that we really don't
want in the first place, instead of encouraging people to use a better
approach helps nobody. We end up with users that think twice about
upgrading, because they will have to use a different paradigm to do the
same stuff, and we have to maintain duplicate stuff. Troubleless it
won't be.
Let's go 1.1 already, and drop this whole shoehorning into 1.0 exercise.
We really have the perfect opportunity here!
> Agreed, the Linux kernel does cache the bos, but currently their does
> not seem to be a way
> to get to the cached bos from userspace, so we need to do some work on
> the linux kernel side
> there too, nothing I cannot write a patch for :)
>
> No idea if the other OS-es do give us access to cached bos descriptors.
Windows does (or at least, Windows has an API to return the BOS if I
recall correctly, but that may still issue a tranfer). I was using that
API in my original patch.
> My usb-3 hub does that too, and it has the brilliant guid in its
> containerID of:
> {00000000-0000-0000-0000-000000000000}
>
> Now that is going to be so useful if I've more then 1 such hub ...
That's because USB-3.0 mandates every USB 3.0 hub to have a Container
ID. Some people choose to do the minimum required I guess...
> I'm not enthusiastic about the notion of a
> libusb_open_with_vid_pid_instance(),
Neither am I. I am however enthusiastic with providing our users with
something that will suit them, regardless of whether this is seen as the
"right" way to approach selection of devices with the same IDs.
> it
> feels too much like adding more duct-tape to a broken concept (opening by
> vid-pid is inherently broken as vid-pid are not necessarily unique, as
> this example clearly shows).
You have to consider this from a user's perspective. If we're lucky
enough, the end user will have some clue about a VID:PID uniquely
identifying the same devices, since that's their whole point. And their
first thought will be that, if they have two devices with same VID:PID,
then the app (through libusbx) should provide a straightforward way to
pick one, with a process of interactive elimination likely to work a lot
better than trying to figure the topology.
> I'm not saying I would nack a patch adding this, but I don't think it is
> a good idea.
The above being said, I'm still open to alternative ideas, and I'm only
considering options.
Then again, forcing every developer to develop their own methods to
separate devices, or using topology when I don't remember seeing one USB
hub that had actual port numbering, ever (and even then, I'd be weary of
the OS picking whatever order it pleases), doesn't strike me as too
great, when we can introduce a simple and hopefully intuitive API based
on user interaction/trial and error (which, while not that elegant has
the merit of being KISS).
> So my plan forward with the BOS / Endpoint Companion USB 3.0 descriptors
> is too
> merge Pete's patch into my darwin-integration tree, with the part I
> NACK-ed above
> fixed using the solution I suggested above.
I'd rather you didn't.
Regards,
/Pete
------------------------------------------------------------------------------
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
