qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Max Reitz <mreitz@redhat.com>, Amit Shah <amit@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	"Denis V. Lunev" <den@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH] virtio: introduce `info virtio' hmp command
Date: Tue, 26 Sep 2017 19:20:20 +0200	[thread overview]
Message-ID: <20170926172020.GC14717@localhost.localdomain> (raw)
In-Reply-To: <1506442418-26026-1-git-send-email-jan.dakinevich@virtuozzo.com>

Am 26.09.2017 um 18:13 hat Jan Dakinevich geschrieben:
> The command is intended for exposing device specific virtio feature bits
> and their negotiation status. It is convenient and useful for debug
> purpose.
> 
> Names of features are taken from a devices via get_feature_name() within
> VirtioDeviceClass. If certain device doesn't implement it, the command
> will print only hexadecimal value of feature mask.
> 
> Cc: Denis V. Lunev <den@virtuozzo.com>
> Signed-off-by: Jan Dakinevich <jan.dakinevich@virtuozzo.com>
> ---
> The patch suggests an another approach for this:
> 
> "virtio: show guest features in 'info qtree'"
> http://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg01609.html

Actually, I think the original approach is much nicer because it uses
generic infrastructure rather than introducing a one-off monitor command
that is specific to a certain class of devices.

But at the same time I can see Cornelia's point that this would create a
whole lot of properties and if we did the same thing consistently for
all devices, the output of 'info qtree' would be completely cluttered
up.

Maybe it would make sense to have properties that can be queried with
QOM, but that don't show up in 'info qtree'? If we then add some HMP
'qom-get' command that allows dumping a whole device as a QOM object
instead of having to query property by property, it should be quite
convenient to use.

Kevin

  parent reply	other threads:[~2017-09-26 17:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-26 16:13 [Qemu-devel] [PATCH] virtio: introduce `info virtio' hmp command Jan Dakinevich
2017-09-26 16:53 ` no-reply
2017-09-26 17:20 ` Kevin Wolf [this message]
2017-09-27  8:46   ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170926172020.GC14717@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=amit@kernel.org \
    --cc=armbru@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=dgilbert@redhat.com \
    --cc=jan.dakinevich@virtuozzo.com \
    --cc=jasowang@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).