From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MQy4B-0005Zd-6v
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 02:34:11 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MQy46-0005U8-DS
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 02:34:10 -0400
Received: from [199.232.76.173] (port=51624 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MQy46-0005Tz-9D
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 02:34:06 -0400
Received: from mx2.redhat.com ([66.187.237.31]:45217)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MQy45-00059K-Nw
	for qemu-devel@nongnu.org; Wed, 15 Jul 2009 02:34:06 -0400
Message-ID: <4A5D769B.7010905@redhat.com>
Date: Wed, 15 Jul 2009 08:26:35 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 04/13] qdev: add generic qdev_device_add()
References: <1247225179-5495-1-git-send-email-kraxel@redhat.com>	<200907101823.07096.paul@codesourcery.com>	<4A57A449.5000907@redhat.com>	<200907102151.04322.paul@codesourcery.com>	<4A5C3689.3070001@redhat.com>
	<87vdluhlut.fsf@pike.pond.sub.org>
In-Reply-To: <87vdluhlut.fsf@pike.pond.sub.org>
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: Markus Armbruster <armbru@redhat.com>
Cc: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

On 07/15/09 01:43, Markus Armbruster wrote:
> Gerd Hoffmann<kraxel@redhat.com>  writes:
>
>> On 07/10/09 22:51, Paul Brook wrote:
>>>>> I think this is going in the wrong direction. The device tree provides us
>>>>> with a standard way of identifying which bus to add a device to. We
>>>>> should be removing uses of pci_create, not adding new ones.
>>>> Why?
>>>>
>>>> Let me guess: Because pci bus numbers are guest-changeable and thus not
>>>> stable?
>>> Because I don't think this code need to be bus specific.
>> Parts of the problem are certainly bus-specific though, such as
>> parsing bus addresses.
>
> Yes.
>
> Provide a bus method to parse the addr property?

Would be an option, yes.

I plan to sort bus= first, then look how to solve the addr= puzzle.

>>>    -device lsi,bus=pci0,id=foo
>>>    -device lsi,bus=pci0,id=bar
>>>    -device scsi-disk,bus=pci0/foo/scsi
>>>    -device scsi-disk,bus=pci0/bar/scsi
>
> Why foo/scsi?  Is there a node "scsi" between the lsi device and the
> disk?  If yes, why?

scsi bus (and we can't skip it as a scsi adapter might have more than 
one bus).

Have hacked up something yesterday, will post RfC patch later today.

cheers,
   Gerd