From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NWoxs-00078h-GA
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 05:36:08 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NWoxn-00073j-Jd
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 05:36:07 -0500
Received: from [199.232.76.173] (port=58287 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NWoxn-00073U-Co
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 05:36:03 -0500
Received: from mx1.redhat.com ([209.132.183.28]:15006)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1NWoxm-0008QT-TE
	for qemu-devel@nongnu.org; Mon, 18 Jan 2010 05:36:03 -0500
Message-ID: <4B543977.8050206@redhat.com>
Date: Mon, 18 Jan 2010 11:35:35 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC,PATCH 08/11] qdev: Add usb_bus_dev_info
References: <1261861899-1984-1-git-send-email-nathan@parenthephobia.org.uk>	<1261861899-1984-9-git-send-email-nathan@parenthephobia.org.uk>	<m31vhrfd6t.fsf@blackfin.pond.sub.org>	<1263593691.2577.2515.camel@athens>
	<m3r5pn4t33.fsf@blackfin.pond.sub.org>
In-Reply-To: <m3r5pn4t33.fsf@blackfin.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: Nathan Baum <nathan@parenthephobia.org.uk>, qemu-devel@nongnu.org

On 01/18/10 11:15, Markus Armbruster wrote:
> Nathan Baum<nathan@parenthephobia.org.uk>  writes:
>
>>>> +static QObject *usb_bus_dev_info(Monitor *mon, DeviceState *qdev)
>>>> +{
>>>> +    USBDevice *dev = DO_UPCAST(USBDevice, qdev, qdev);
>>>> +    USBBus *bus = usb_bus_from_device(dev);
>>>> +    return qobject_from_jsonf("{'busnr': %d, 'addr':%d, 'speed': %s, 'desc': %s, 'attached': %i}",
>>>> +                              bus->busnr,
>>>
>>> As for PCI, 'busnr' belongs to the bus, not the device.

You want be able to figure which bus the device is attached to.

I think you actually can because the command returns the device tree 
converted into a qobject tree, correct?

Note: busnr is *not* fixed, it can be changed by the guest (maybe not 
for the primary, but surely for any secondary by writing to a pci bridge 
register).

>> Hmm. In cases like this, is it appropriate to modify the output of the
>> existing "info qtree" when it is modified to use the QObject data?
 >>
>> Would it be sensible to go the (probably small amount of) effort to
>> change the print functions to print exactly they do now, and put changes
>> to their output in different patches so they can easily be dropped if
>> necessary?
>
> We might want to change info qtree output anyway if we show bus
> information separately there...

Indeed.

>>> Hmm, we don't have the infrastructure to return bus information, yet.
>>> "info qtree" hardcodes printing of name and type.  Gerd, what do you
>>> think?

Adding a ->print_bus() function (or whatever the qmp aequivalent will 
be) to BusInfo is fine with me.

> Regardless, I think we should first decide what data we want to transmit
> over QMP, and how to structure it, then figure out if and how to change
> its human readable presentation.

Sounds like a plan ;)

cheers,
   Gerd