Re: [Qemu-devel] [RFC,PATCH 08/11] qdev: Add usb_bus_dev_info

[Gerd Hoffmann <kraxel@redhat.com>]

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