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

[Gerd Hoffmann]

On 01/18/10 11:15, Markus Armbruster wrote:
> Nathan Baum<address@hidden>  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