[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH, RFC 0/4] monitor device info infrastructure
From: |
Blue Swirl |
Subject: |
[Qemu-devel] Re: [PATCH, RFC 0/4] monitor device info infrastructure |
Date: |
Thu, 13 May 2010 21:50:53 +0300 |
On 5/13/10, Jan Kiszka <address@hidden> 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.