[haiku-commits] Re: r42812 - in haiku/trunk: headers/os/device src/add-ons/kernel/drivers/bus/usb src/kits/device

  • From: Philippe Houdoin <philippe.houdoin@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 9 Oct 2011 19:44:56 +0200

Hi Michael,

> Could you please expain what you are trying to solve?

Well, libusb requires to be able to return the *whole* descriptor, and
applications using this API expect to find the whole one.
Because they parse it themselves, something libusb don't really wrap.

> The configuration descriptor is supposed to only consist of interface 
> descriptors that
> then contain endpoint and generic descriptors.
> All of those can be
> enumerated via the corresponding BUSBConfiguration/BUSBInterface members
> (BUSBInterface::OtherDescriptorAt() would be for enumerating generic
> descriptors). This is also true for non-active configuration/interface
> descriptors.

But, alas, descriptors order could mater.
As I found out. Initially, I did exactly what you suggest here:
rebuild the whole configuration descriptor by iterating them via USB
Kit API.
Unfortunatly, the USB2 companion descriptors then where either placed
before or after endpoint descriptors, depending on when I was
appending it along all other interface generic descriptors. But these
specific descriptors must follow right after the endpoint descriptor!

With some more work, I could theorically find a way to place theses in
the right place, but
1) it will only works if the order in which
BUSBInterface::GenericDescriptorAt() is the same than in the
configuration descriptor, which may not be warranted in the future
2) new descriptors in the future may needs too to appear in a specific
order, which will break again the rebuild process, and
3) from kernelland anyone can retrieve from USB stack this full
descriptor as transmitted by device, so I failed to see why userland
can't either, something which will fix my needs and avoid 1) and 2)

The issue is mostly about not breaking USBKit ABI, which is why I
asked for proofreading.

> Please keep the pointer style consistent with the rest of the file.
> Especially when it's obvious as in this case where the next pointer is
> just a few lines up.

Oops, my bad.
I'll fix it. Thanks.

> Adding that there will break the old-USBKit <-> usb_raw interface,

Are you sure?

IIRC, the _ETC opcodes were added already for Haiku and were not
present in BeOS's USBKit.h
I've just add this one before the GET_INTERFACE_DESCRIPTOR_ETC and
GET_ENDPOINT_DESCRIPTOR_ETC opcodes to keep the logical configuration
/ interface / endpoint orders.

And it's still compatible with the
missed something.

> which up until now was still compatible (i.e. stuff built with USBKit.a
> under BeOS would work due to the fixed ioctl interface against
> usb_raw).

I'll try to find BeOS USBKit headers to check, but my impression was
that it break the existing opcodes, just add another one.


Other related posts: