From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45385 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCePo-0001kq-Uc for qemu-devel@nongnu.org; Thu, 13 May 2010 15:49:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCeF7-00051S-Iy for qemu-devel@nongnu.org; Thu, 13 May 2010 15:38:51 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:47522) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCeF7-00051B-7c for qemu-devel@nongnu.org; Thu, 13 May 2010 15:38:49 -0400 Message-ID: <4BEC553E.90901@web.de> Date: Thu, 13 May 2010 21:38:38 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4BEBACE5.4010306@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig06777823EB178820FDAE7DC3" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH, RFC 0/4] monitor device info infrastructure List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig06777823EB178820FDAE7DC3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blue Swirl wrote: > On 5/13/10, Jan Kiszka wrote: >> Blue Swirl wrote: >> > Hi all, >> > >> > I finally refreshed some of my monitor patches. PCI and HPET patche= s >> > (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 ad= ded >> > 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 " 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). >=20 > 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? That should be addressed differently (if there is a need to change it). My point is basically about things that are (or will be) qdev related - just as dev_info was suggesting. >=20 >> 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= >> " command instead of mixing both usages under an info comm= and. >=20 > 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. If they are special, then I would vote for a separate stats infrastructure with its own data types where required. If certain stats should rather be enabled by default, then there is actually the question if they shouldn't be migrated as well, thus become part of the related VMState definitions. Just thoughts, I haven't done any investigations on the current situation. However, I'm a fan of a plug-in interface for the existing info monitor command. That would allow to register things dynamically that do not fit in any regular structure without requiring stubs or tons of #ifdefs. What about this as a first step? Jan --------------enig06777823EB178820FDAE7DC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkvsVUYACgkQitSsb3rl5xR+bACdGzGeEJwJfoJYbBfTNMr7jAmz IYsAnRTLewe7PBM0MENc66Dn3U5ETGZP =mSQV -----END PGP SIGNATURE----- --------------enig06777823EB178820FDAE7DC3--