All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel@nongnu.org, "Ani Sinha" <anisinha@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	devel@lists.libvirt.org
Subject: Re: [RFC PATCH 00/10] hw/misc/vmcoreinfo: Convert from QDev to plain Object
Date: Thu, 19 Dec 2024 15:57:29 +0000	[thread overview]
Message-ID: <Z2RCaZrwjYSM3NpV@redhat.com> (raw)
In-Reply-To: <20241219153857.57450-1-philmd@linaro.org>

On Thu, Dec 19, 2024 at 04:38:47PM +0100, Philippe Mathieu-Daudé wrote:
> No reason for vmcoreinfo to be based on QDev, since it
> doesn't use any QDev API. Demote to plain Object.

I'm not especially convinced by that rationale, at least in the short
term[1].

As a user of QEMU, I would tend to view -device  as being the way to
create devices that are visible to the guest, and -object as being
for dealing with host backends.

vmcoreinfo is quite an unusal device, in that if only exists as a
fwcfg field, but that's an internal impl detail from a user's POV,
and it is still a guest visible device type.

So while it may not leverage QDev API, I still feel it is more of
a fit for -device, than -object.  Is there any functional benefit
to moving it to -object, that outweighs the disruption ?


With regards,
Daniel

[1] I say "short term", because overall I'm of the opinion that
-device, -machine, -cpu, -chardev, etc should not exist, and
-object ought to be made capable of instantiating any type of
object whatever subclass it might be. I doubt that will change
any time in the forseeable future though, so it is more of a
hypothetical point.

-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  parent reply	other threads:[~2024-12-19 16:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19 15:38 [RFC PATCH 00/10] hw/misc/vmcoreinfo: Convert from QDev to plain Object Philippe Mathieu-Daudé
2024-12-19 15:38 ` [RFC PATCH 01/10] hw/misc/vmcoreinfo: Declare QOM type using DEFINE_TYPES macro Philippe Mathieu-Daudé
2024-12-19 16:54   ` Daniel P. Berrangé
2024-12-19 15:38 ` [RFC PATCH 02/10] hw/misc/vmcoreinfo: Rename opaque pointer as 'opaque' Philippe Mathieu-Daudé
2024-12-19 16:55   ` Daniel P. Berrangé
2024-12-19 15:38 ` [RFC PATCH 03/10] hw/misc/vmcoreinfo: Un-inline vmcoreinfo_find() Philippe Mathieu-Daudé
2024-12-19 16:57   ` Daniel P. Berrangé
2024-12-19 15:38 ` [RFC PATCH 04/10] hw/misc/vmcoreinfo: Rename VMCOREINFO_DEVICE -> TYPE_VMCOREINFO_DEVICE Philippe Mathieu-Daudé
2024-12-19 16:59   ` Daniel P. Berrangé
2024-12-19 17:12     ` Philippe Mathieu-Daudé
2024-12-19 15:38 ` [RFC PATCH 05/10] hw/misc/vmcoreinfo: Convert to three-phase reset interface Philippe Mathieu-Daudé
2024-12-19 17:00   ` Daniel P. Berrangé
2024-12-19 15:38 ` [RFC PATCH 06/10] hw/misc/vmcoreinfo: Move vmstate_vmcoreinfo[] around Philippe Mathieu-Daudé
2024-12-19 15:38 ` [RFC PATCH 07/10] hw/misc/vmcoreinfo: Factor vmcoreinfo_device_realize() out Philippe Mathieu-Daudé
2024-12-19 15:38 ` [RFC PATCH 08/10] hw/misc/vmcoreinfo: Implement 'vmcore-info' object Philippe Mathieu-Daudé
2024-12-20  8:50   ` Marc-André Lureau
2024-12-20 10:53     ` Philippe Mathieu-Daudé
2024-12-19 15:38 ` [RFC PATCH 09/10] hw/misc/vmcoreinfo: Deprecate '-device vmcoreinfo' Philippe Mathieu-Daudé
2024-12-19 15:38 ` [RFC PATCH-for-10.2 10/10] hw/misc/vmcoreinfo: Remove legacy " Philippe Mathieu-Daudé
2024-12-19 15:57 ` Daniel P. Berrangé [this message]
2024-12-19 16:19   ` [RFC PATCH 00/10] hw/misc/vmcoreinfo: Convert from QDev to plain Object Ani Sinha
2024-12-19 16:48   ` Philippe Mathieu-Daudé

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=Z2RCaZrwjYSM3NpV@redhat.com \
    --to=berrange@redhat.com \
    --cc=anisinha@redhat.com \
    --cc=devel@lists.libvirt.org \
    --cc=marcandre.lureau@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.