On 5/13/10, Jan Kiszka <jan.kis...@web.de> wrote: > Blue Swirl wrote: > > Hi all, > > > > I finally refreshed some of my monitor patches. PCI and HPET patches > > (attached, they don't apply anymore) need more work because of the new > > monitor design. > > > > The patches provide a method for devices to register new monitor > > commands. This fixes some design problems, like useless > > pic_info/irq_info functions for most architectures. > > > > I think automation via qdev field was requested the last time. I added > > something like this, though it doesn't fit the cases where several > > functions need to be registered. > > > > Comments? > > > I'll soon send out a series that adds "device_show <qdev-path>" to > visualize the full state, something that will at least obsolete "info > pic" and "info hpet" sooner or later, maybe even more. Also, I would > like to qdev'ify CPUs in order to make them reachable for device_show > (which evaluates qdev->info.vmstate).
That sounds like much better design. But for example 'info pci' shows different things compared to 'info qdev'. And what about 'info usbhost', there is no qdev? > I'm not sure: How many use cases for a "dev_info" would remain? > Moreover, to dump statistics, we should rather add some "device_stats > <qdev-path>" command instead of mixing both usages under an info command. Not too many. I think the VMState structure (with no connection to savevm/loadvm/migration) would be useful to define and dump also statistics. But because most statistics need to be enabled at compile phase, they are probably not very widely used.
