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