No reason for vmcoreinfo to be based on QDev, since it
doesn't use any QDev API. Demote to plain Object.

Since we can only register one type, introduce a new
one for object: 'vmcore-info' (dash separator), keeping
'vmcoreinfo' device during the deprecation period.

Philippe Mathieu-Daudé (10):
  hw/misc/vmcoreinfo: Declare QOM type using DEFINE_TYPES macro
  hw/misc/vmcoreinfo: Rename opaque pointer as 'opaque'
  hw/misc/vmcoreinfo: Un-inline vmcoreinfo_find()
  hw/misc/vmcoreinfo: Rename VMCOREINFO_DEVICE -> TYPE_VMCOREINFO_DEVICE
  hw/misc/vmcoreinfo: Convert to three-phase reset interface
  hw/misc/vmcoreinfo: Move vmstate_vmcoreinfo[] around
  hw/misc/vmcoreinfo: Factor vmcoreinfo_device_realize() out
  hw/misc/vmcoreinfo: Implement 'vmcore-info' object
  hw/misc/vmcoreinfo: Deprecate '-device vmcoreinfo'
  hw/misc/vmcoreinfo: Remove legacy '-device vmcoreinfo'

 docs/about/removed-features.rst |   5 +
 include/hw/misc/vmcoreinfo.h    |  26 ++---
 hw/misc/vmcoreinfo.c            | 167 +++++++++++++++++++-------------
 3 files changed, 116 insertions(+), 82 deletions(-)

-- 
2.47.1

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 :|

On 19/12/24 16:57, Daniel P. Berrangé wrote:
> 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.

Hmm.

> 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 ?

No.

Patches 1-5 are still useful cleanups although.

> [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.

Agreed.

On Thu, 19 Dec, 2024, 9:27 pm Daniel P. Berrangé, <berrange@redhat.com>
wrote:

> 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.


+1 to this.

Is there any functional benefit
> to moving it to -object, that outweighs the disruption ?


>