[RFC,00/10] hw/misc/vmcoreinfo: Convert from QDev to plain Object

Message

Philippe Mathieu-Daudé Dec. 19, 2024, 3:38 p.m. UTC

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(-)

Comments

Daniel P. Berrangé Dec. 19, 2024, 3:57 p.m. UTC | #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.

Ani Sinha Dec. 19, 2024, 4:19 p.m. UTC | #2

On Thu, 19 Dec, 2024, 9:27 pm Daniel P. Berrangé, <[e-mail]>
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 ?


>

Philippe Mathieu-Daudé Dec. 19, 2024, 4:48 p.m. UTC | #3

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.