[Top][All Lists]

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

Re: [RFC PATCH 00/12] QOM/QAPI integration part 1

From: Paolo Bonzini
Subject: Re: [RFC PATCH 00/12] QOM/QAPI integration part 1
Date: Thu, 4 Nov 2021 13:39:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

On 11/4/21 10:07, Kevin Wolf wrote:
Also, for the obligatory bikeshedding remark, do you have any other plans or
ideas for the colon-separated auto generated typenames?  Having both the
"namespace" (qom) and the more specific use (config) before the classname is
a bit weird, compared to the existing structs like RngRandomProperties.
Especially if boxed config is more used (or becomes the only possibility),
it might be that qom:class-name:config, or even just class-name:config, make
for nicer code in the object implementation.

'qom-config:classname' isn't a type that is useful for the object
implementations at all. Its only use is really storing the whole
configuration temporarily in a QAPI C struct before applying it.

It would be useful as the (auto-boxed) argument of the configuration code. So basically you'd not need the RngProperties function anymore because you use something like QomConfigRngBackend (or RngBackendQomConfig - hence the question on how to name the auto-generated types).

The class implementations always want to store only their "local" config
options, but 'qom-config:classname' contains those of the parent class
as well.

Ah, I didn't understand that (hence the rubbish tag above). It makes sense given that instance_config is called per-class while ObjectOptions stores all the info in one class. That's a major change from my sketch, which planned to call the base class config function by hand (and handle the marshalling via QAPI 'base': '...').

Oh, and I also wanted to say something about why not just directly using
the class name, which was my first idea: 'foo': 'iothread' looks more
like referencing an existing iothread rather than the configuration for
a new one. I wanted to leave us the option that we could possibly later
take a string for such options (a QOM path) and then pass the referenced
object to QMP commands as the proper QOM type.

I agree that 'iothread' is going to be confusing when you're referring to the configuration.

Anyway I'm totally fine with 'qom-config:classname'. Given this explanation, however, one alternative that makes sense could be 'classname:full-config'. Then you could use 'classname:config' for the autoboxed configs---and reserve 'classname' to mean the pointer to an object. Classes are (generally) lowercase and QAPI structs are CamelCase, so there is not much potential for collisions.


reply via email to

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