qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	lvivier@redhat.com, thuth@redhat.com, pkrempa@redhat.com,
	berrange@redhat.com, qemu-block@nongnu.org,
	libvir-list@redhat.com, armbru@redhat.com, jasowang@redhat.com,
	qemu-devel@nongnu.org, mreitz@redhat.com, kraxel@redhat.com
Subject: Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
Date: Wed, 2 Dec 2020 14:26:44 +0100	[thread overview]
Message-ID: <69dff34f-d87b-3a8d-640f-35f6bf5db75c@redhat.com> (raw)
In-Reply-To: <20201202125124.GD3836@habkost.net>

On 02/12/20 13:51, Eduardo Habkost wrote:
>>> I'm liking the direction this is taking.  However, I would still
>>> like to have a clearer and feasible plan that would work for
>>> -device, -machine, and -cpu.
>>
>> -cpu is not a problem since it's generally created with a static
>> configuration (now done with global properties, in the future it could be a
>> struct).
> 
> It is a problem if it requires manually converting existing code
> defining CPU properties and we don't have a transition plan.

We do not have to convert everything _if_ for some objects there are 
good reasons to do programmatically-generated properties.  CPUs might be 
one of those cases (or if we decide to convert them, they might endure 
some more code duplication than other devices because they have so many 
properties).

> Would a -device conversion also involve non-user-creatable
> devices, or would we keep existing internal usage of QOM
> properties?
> 
> Even if it's just for user-creatable devices, getting rid of QOM
> property usage in devices sounds like a very ambitious goal.  I'd
> like us to have a good transition plan, in addition to declaring
> what's our ideal end goal.

For user-creatable objects Kevin is doing work in lockstep on all 
classes; but once we have the infrastructure for QAPI object 
configuration schemas we can proceed in the other direction and operate 
on one device at a time.

With some handwaving, something like (see create_unimplemented_device)

     DeviceState *dev = qdev_new(TYPE_UNIMPLEMENTED_DEVICE);

     qdev_prop_set_string(dev, "name", name);
     qdev_prop_set_uint64(dev, "size", size);
     sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);

might become something like

     { 'object': 'unimplemented-device',
       'config': {
          'name': 'str',
          'size': 'size'
       },
     }

     DeviceState *dev = qapi_Unimplemented_new(&(
          (UnimplementedDeviceOptions) {
              .name = name,
              .size = size
          }, &error_fatal);
     object_unref(dev);

(i.e. all typesafe!) and the underlying code would be something like

     void (*init_properties)(Object *obj, Visitor *v, Error **errp);
     ...

     // QAPI generated constructor
     UnimplementedDevice *qapi_Unimplemented_new(
         UnimplementedDeviceOptions *opt, Error **errp)
     {
         Object *obj = object_new(TYPE_UNIMPLEMENTED_DEVICE);
         if (!qapi_Unimplemented_init_properties(obj, opt, errp)) {
             object_unref(obj);
             return NULL;
         }
         return obj;
     }

     // QAPI generated Visitor->struct adapter
     bool qapi_Unimplemented_init_properties(
         Object *obj, Visitor *v, Error **errp)
     {
         UnimplementedDeviceOptions opt;
         Error *local_err = NULL;
         visit_type_UnimplementedDeviceOptions(v, NULL,
                                               &opt, &local_err);
         if (local_err) {
             error_propagate(errp, local_err);
             return false;
         }
         unimplemented_init_properties(UNIMPLEMENTED_DEVICE(obj),
                                       &opt, &local_err);
         if (local_err) {
             error_propagate(errp, local_err);
             return false;
         }
         return true;
     }

     // Hand-written (?) initializer:
     void unimplemented_init_properties(Object *obj,
          UnimplementedDeviceOptions *opt, Error **errp)
     {
          obj->name = name;
          obj->size = size;
          device_realize(obj, errp);
     }

     // class_init code:
     oc->init_properties = qapi_Unimplemented_init_properties;

and all read-only-after-realize QOM properties could be made *really* 
read-only.

Paolo



  reply	other threads:[~2020-12-02 13:28 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 12:25 [PATCH 00/18] qapi/qom: QAPIfy object-add Kevin Wolf
2020-11-30 12:25 ` [PATCH 01/18] qapi/qom: Add ObjectOptions for iothread Kevin Wolf
2020-11-30 15:00   ` Paolo Bonzini
2020-11-30 15:54     ` Kevin Wolf
2020-11-30 12:25 ` [PATCH 02/18] qapi/qom: Add ObjectOptions for authz-* Kevin Wolf
2020-11-30 12:25 ` [PATCH 03/18] qapi/qom: Add ObjectOptions for cryptodev-* Kevin Wolf
2020-11-30 12:25 ` [PATCH 04/18] qapi/qom: Add ObjectOptions for dbus-vmstate Kevin Wolf
2020-11-30 12:25 ` [PATCH 05/18] qapi/qom: Add ObjectOptions for memory-backend-* Kevin Wolf
2020-11-30 12:25 ` [PATCH 06/18] qapi/qom: Add ObjectOptions for rng-*, deprecate 'opened' Kevin Wolf
2020-11-30 12:25 ` [PATCH 07/18] qapi/qom: Add ObjectOptions for throttle-group Kevin Wolf
2020-11-30 12:25 ` [PATCH 08/18] qapi/qom: Add ObjectOptions for secret*, deprecate 'loaded' Kevin Wolf
2020-11-30 12:25 ` [PATCH 09/18] qapi/qom: Add ObjectOptions for tls-*, " Kevin Wolf
2020-11-30 12:25 ` [PATCH 10/18] qapi/qom: Add ObjectOptions for can-* Kevin Wolf
2020-11-30 12:25 ` [PATCH 11/18] qapi/qom: Add ObjectOptions for colo-compare Kevin Wolf
2020-11-30 12:25 ` [PATCH 12/18] qapi/qom: Add ObjectOptions for filter-* Kevin Wolf
2020-11-30 12:25 ` [PATCH 13/18] qapi/qom: Add ObjectOptions for pr-manager-helper Kevin Wolf
2020-11-30 12:25 ` [PATCH 14/18] qapi/qom: Add ObjectOptions for sev-guest Kevin Wolf
2020-11-30 12:25 ` [PATCH 15/18] qapi/qom: Add ObjectOptions for input-* Kevin Wolf
2020-11-30 12:25 ` [PATCH 16/18] tests: Drop 'props' from object-add calls Kevin Wolf
2020-11-30 12:25 ` [PATCH 17/18] qapi/qom: Drop deprecated 'props' from object-add Kevin Wolf
2020-11-30 12:25 ` [PATCH 18/18] qapi/qom: QAPIfy object-add Kevin Wolf
2020-11-30 14:58 ` [PATCH 00/18] " Paolo Bonzini
2020-11-30 15:30   ` Daniel P. Berrangé
2020-11-30 16:13     ` Kevin Wolf
2020-11-30 16:52       ` Daniel P. Berrangé
2020-11-30 16:32     ` Paolo Bonzini
2020-12-01  8:36       ` Markus Armbruster
2020-11-30 15:46   ` Kevin Wolf
2020-11-30 16:57     ` Paolo Bonzini
2020-11-30 18:10       ` Kevin Wolf
2020-11-30 19:35         ` Paolo Bonzini
2020-12-01 16:20           ` Kevin Wolf
2020-12-01 17:16             ` Paolo Bonzini
2020-12-01 18:28               ` Eduardo Habkost
2020-12-01 19:35               ` Kevin Wolf
2020-12-01 21:23                 ` Paolo Bonzini
2020-12-01 22:08                   ` Eduardo Habkost
2020-12-02  9:30                     ` Paolo Bonzini
2020-12-02 10:38                       ` Kevin Wolf
2020-12-02 12:30                         ` Paolo Bonzini
2020-12-02 12:51                       ` Eduardo Habkost
2020-12-02 13:26                         ` Paolo Bonzini [this message]
2020-12-02 13:54                           ` Eduardo Habkost
2020-12-02 15:17                             ` Kevin Wolf
2020-12-02 16:05                               ` Eduardo Habkost
2020-12-02 17:35                                 ` Kevin Wolf
2020-12-02 19:45                                   ` Eduardo Habkost
2020-12-03  6:46                                   ` Gerd Hoffmann
2020-12-03 14:58                                     ` Eduardo Habkost
2020-12-03 11:11                                   ` Paolo Bonzini
2020-12-03 15:15                                     ` Kevin Wolf
2020-12-03 16:50                                       ` Paolo Bonzini
2020-12-03 17:43                                         ` Kevin Wolf
2020-12-03 18:01                                           ` Paolo Bonzini
2020-12-03 17:52                                         ` Eduardo Habkost
2020-12-03 18:10                                           ` Paolo Bonzini
2020-12-03 18:19                                             ` Eduardo Habkost
2020-12-02 10:27                   ` Kevin Wolf
2020-12-02 12:41                     ` Paolo Bonzini
2020-11-30 18:58 ` Peter Krempa

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=69dff34f-d87b-3a8d-640f-35f6bf5db75c@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@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).