|
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.
<rubbish>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).
</rubbish>
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.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |