[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




>>> On 9/14/2015 at 10:03 PM, in message
<CAFLBxZayaqTeJiB3RfG8qHxjCzQy8BBTe0Hxj+FT6ABSLf+Ntg@xxxxxxxxxxxxxx>, George
Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote: 
> 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. 

So can we agree to use uint8 for hostbus and hostaddr as libusb does?

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.