[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/18] qapi/qom: QAPIfy object-add

From: Paolo Bonzini
Subject: Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
Date: Thu, 3 Dec 2020 17:50:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 03/12/20 16:15, Kevin Wolf wrote:
I don't think this is an intermediate state like Eduardo wants to have.
Creating the object, then setting properties, then realize [1] will fail
after your change. But keeping it working was the whole point of the

With the sample code, you must remove object_class_property_set calls at the same time as you remove the setters. Usually that'd be when you convert to QAPI and oc->configure, but it doesn't have to be that way if there are good reasons not to do so.

Also, it still allows you to do so one class at a time, and I *think* the presence of subclasses or superclasses doesn't matter (only whether properties are still writable). We can use chardevs (see ChardevCommon in qapi/char.json) to validate that before tackling devices.

(In fact, this means that your series---plus -object and object_add conversion---would be good, pretty much unchanged, as a first step. The second would be adding oc->configure and object_configure, and converting all user-creatable objects to oc->configure. The third would involve QAPI code generation).

I'm also not really sure why you go from RngEgdOptions to QObject to a
visitor, only to reconstruct RngEgdOptions at the end.

The two visits are just because you cannot create an input visitor directly on C data. I stole that from your patch 18/18 actually, just with object_new+object_configure instead of user_creatable_add_type.

But I wouldn't read too much in the automatically-generated *_new functions since they are already in QAPI code generator territory. Instead the basic object_configure idea can be applied even without having automatic code generation.

I think the class
implementations should have a normal C interface without visitors and we
should be able to just pass the existing RngEgdOptions object (or the
individual values for its fields for 'boxed': false).

Sure, however that requires changes to the QAPI code generator which was only item (3) in your list list. Until then you can already work with a visitor interface:

  void rng_egd_configure(Object *obj, Visitor *v, Error **errp)
      RngEgd *s = RNG_EGD(obj);
      s->config = g_new0(MemoryBackendOptions, 1);
      visit_type_MemoryBackendOptions(v, NULL, &s->config, errp);

      s->config->share = (s->config->has_share
                          ? s->config->share : false);

but if you had a QAPI description

  { 'object': 'RngEgd',
    'qom-type': 'rng-egd',
    'configuration': 'RngEgdOptions',
    'boxed': true

the QAPI generator could produce the oc->configure implementation. Similar to commands, that implementation would be an unmarshaling wrapper that calls out to the natural C interface:

  void qapi_RngEgd_configure(Object *obj, Visitor *v, Error **errp);
      Error *local_err = NULL;
      g_autoptr(MemoryBackendOptions) *config =
          g_new0(MemoryBackendOptions, 1);
      visit_type_MemoryBackendOptions(v, NULL, &s->config, &local_err);
      if (local_err) {
          error_propagate(errp, local_err);
      qom_rng_egd_configure(RNG_EGD(obj), config, errp);

  void qom_rng_egd_configure(RngEng *s,
                             RngEgdOptions *config,
                             Error **errp)
      config->share = (config->has_share
                       ? config->share : false);
      s->config = QAPI_CLONE(RngEgdOptions, config);


reply via email to

[Prev in Thread] Current Thread [Next in Thread]