From mboxrd@z Thu Jan  1 00:00:00 1970
From: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH V6 3/7] libxl: add pvusb API
Date: Mon, 14 Sep 2015 13:23:33 +0200
Message-ID: <55F6AE35.8050301@suse.com>
References: <1439202928-24813-1-git-send-email-cyliu@suse.com>
	<1439202928-24813-4-git-send-email-cyliu@suse.com>
	<1441721852.24450.120.camel@citrix.com>
	<55F2F64F02000066000508CA@relay2.provo.novell.com>
	<1441978018.3549.33.camel@citrix.com> <55F2DD66.1040507@suse.com>
	<1441980590.3549.46.camel@citrix.com> <55F2E29D.10805@suse.com>
	<1441982504.3549.69.camel@citrix.com> <55F6438A.7090403@suse.com>
	<CAFLBxZbWH6LxKxuaTbcnv1rJB8ar4G_WOPfki2YzUc3QqoEszw@mail.gmail.com>
	<55F6A729.3080301@suse.com>
	<22006.43915.2549.265495@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <22006.43915.2549.265495@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Chun Yan Liu <cyliu@suse.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jim Fehlig <JFEHLIG@suse.com>, Simon Cao <caobosimon@gmail.com>
List-Id: xen-devel@lists.xenproject.org

On 09/14/2015 01:12 PM, Ian Jackson 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.

Agreed.

> 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 ?

uint128_t ? ;-)

I think 24 bits should be more than enough. Nobody will accept such huge
numbers without any need: they are to be used by users.


Juergen