From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MGDn3-0007TH-9V
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:08:05 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MGDmw-0007N6-PG
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:08:03 -0400
Received: from [199.232.76.173] (port=42353 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MGDmv-0007Mo-Nv
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:07:57 -0400
Received: from qw-out-1920.google.com ([74.125.92.144]:41125)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1MGDmu-0005hs-Ut
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:07:57 -0400
Received: by qw-out-1920.google.com with SMTP id 4so1822711qwk.4
	for <qemu-devel@nongnu.org>; Mon, 15 Jun 2009 08:07:56 -0700 (PDT)
Message-ID: <4A3663C6.3070801@codemonkey.ws>
Date: Mon, 15 Jun 2009 10:07:50 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3
	03/13] qemu: add routines to manage PCI capabilities]
References: <20090610150129.GC28601@redhat.com>
	<200906101624.30659.paul@codesourcery.com>
	<20090610174301.GC7416@shareable.org>
	<20090610182227.GN28601@redhat.com>
	<20090610192702.GH7416@shareable.org>
	<1244796209.16425.20.camel@blaa> <4A326B5C.5010501@codemonkey.ws>
	<1244821292.30522.56.camel@blaa> <4A327E4A.7010300@codemonkey.ws>
	<1244825303.26769.19.camel@blaa> <20090614095016.GA7560@redhat.com>
	<4A3617D4.5090405@redhat.com> <4A36424D.3080901@codemonkey.ws>
	<4A364698.1090402@redhat.com> <4A364A9B.9070001@codemonkey.ws>
	<4A364E32.4010808@redhat.com> <4A365078.5080209@codemonkey.ws>
	<4A36529D.4060200@redhat.com>
In-Reply-To: <4A36529D.4060200@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>, Rusty Russell <rusty@rustcorp.com.au>, kvm@vger.kernel.org, Mark McLoughlin <markmc@redhat.com>, Glauber Costa <glommer@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl <blauwirbel@gmail.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Paul Brook <paul@codesourcery.com>

Avi Kivity wrote:
>
> I'd object to any implicit addressing rules.  If we have to say 
> target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of 
> index=8345345235 so be it.

The next observation is that while we expand the SCSI addressing, the 
current propose flattens the PCI hierarchy (i.e. pci_addr=00:01.0).

An alternative would be to either always expand or always flatten 
addressing.  I think the later has a lot of merit.  Consider:

-controller type=lsi1234,addr=00:01,name=blah
-controller-disk controller=blah,addr=00:01,name=sda

-controller type=ide,addr=00.02,name=ide
-controller-disk controller=ide,addr=3,name=hdd

-drive file=foo.img,controller-disk=sda
-drive file=bar.img,controller-disk=hdd

This means that addr's format depends on the parent device node which is 
a bit less explicit than the previous example.  However, it is much more 
consistent and easier to implement.  Basically, when adding a device to 
it's parent, you hand the parent the "addr" field and that lets you say 
where you want to sit on the bus.

Regards,

Anthony Liguori