Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Sep 14, 2015 at 12:12 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API"):
>> On 09/14/2015 12:36 PM, George Dunlap wrote:
>> > Anyone want to look into the Linux source code to find out how big it
>> > will allow busnum / devnum to grow?
>>
>> drivers/usb/core/hcd.c is using a bitmap to find the next bus number
>> currently not in use. It's size is USB_MAXBUS which in turn has the
>> value 64.
>>
>> choose_devnum() in drivers/usb/core/hub.c is doing a similar job for
>> device numbers. Here the highest number supported is 127.
>
> We are defining an API, which shouldn't involve this kind of
> implementation-grobbling.
>
> At an API level, it seems that this Linux busnum is not documented to
> have any particular number or behaviour or range or anything.  We
> should use the biggest type we can use conveniently
>
> Do we need to worry that some bus might have 2^24 unplugs/plugs
> (perhaps in some kind of software emulation) and that we need to use a
> type which can hold a uint32_t or maybe even a uint64_t ?

libusb is already a published API that supports uint8, or up to 255.
Following their lead seems like a reasonable thing to do.  If ever
that number goes above 255, basically every Linux program that touches
a USB device will need to be recompiled with a new version of libusb.

Is there any reason for Linux to go above 255?  Things I can think of:

1. Users have more than 255 devices plugged into the same bus.

2. A security / confusion issue due to devnum reuse when users plug
and unplug devices hundreds of times.

Both of these seem pretty unlikely.

I would personally go with uint8, but int16 or int32 certainly won't hurt.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel