Il mer 15 gen 2020, 10:21 Markus Armbruster <
address@hidden> ha scritto:
> We don’t want the QAPI to let arbitrary fields of a QOM object
> be modified, do we?
We already do: QMP command qom-set. If it breaks your guest, you get to
keep the pieces.
That's not true. We chose not to make that a "recommended" interface, and instead we add new commands. However that's mostly to avoid tying our hands and not making too much of QOM part of the API. But I would be very surprised if a guest could be broken with qom-set.
This was definitely not the case when QOM was introduced in a half-baked state, but let's not indulge in self-flagellation more than it's actually necessary.
> As for the “public” aspects of a QOM object, that is static if it
> comes from QAPI, so why couldn’t we define it there?
QAPI specifies a certain kind of data types.
QOM "specifies" data types as an imperative program for creating them.
Maximally flexible, and fundamentally at odds with static analysis.
I've hated this since day one.
There's no hard reason why QOM could not specify static aspects
declaratively. It just doesn't, and changing it now would be a
monumental task.
The imperative program mostly creates identical data types every time.
In other words, the data types are static. Two problems. One,
converting such a program to an equivalent declaration takes manual
labor. Two, there are exceptions, and identifying them is more manual
labor.
>>> the same way, QAPI can't say anything about the structure of a QOM
>>> object, and I think that's a problem.
>>>
>>>>> - which, as far as I
>>>>> understand, is mainly because QOM properties aren't necessarily static,
>>>>> so we can't provide a statically defined interface for them. Probably
>>>>> solvable in QEMU, but not without a major effort.
>>>>
>>>> Or maybe extend the language so that it’s internal semantics
>>>> knows about this aspect of QOM?
>>>
>>> My point is that for example you can't generate a C struct (which is
>>> statically defined) from something that has a dynamic structure. The
>>> best you could do is fall back to key=value even in the C source, both
>>> key and value being strings. But then you still have to parse these
>>> strings manually, so it doesn't actually help much compared to a state
>>> without C bindings.
>
> I really don’t understand that point. To me, all these operations
> seem relatively simple to generate.
Yes, if the QAPI fairy gives us a declarative specification equivalent
to the existing imperative one, then replacing the hand-written
imperative code by code generated from the declarative specification
would be relatively simple.
> I think that what confuses me is when you write “something that has a
> dynamic structure”. I understand that as referring to the structure
> defined in the schema. But the schema itself is static. So you can
> generate static code from it, and it’s already done today.
QAPI data types are static.
QOM types are not. They're effectively almost static in practice.
> Another hypothesis on my side is that we don’t want, ever, to
> have the API provide for example the option to create its own
> arbitrary QOM classes, or to tag arbitrary properties to an object,
> where by “arbitrary” I mean not explicitly mentioned somewhere in
> something like the schema.
>
> So I suspect you are talking about something else.
Kevin's talking about the imperative code creating different QOM
properties depending on how and in what context it is run.
QOM is perfectly capable of supporting a QMP command to add arbitrary
QOM properties to an object at run time, or even add arbitrary QOM
types, but as you wrote we don't want that.
>> QOM and QAPI sabotage each other. Ironic, considering they were dreamed
>> up by the same guy :)
>>
>> QAPI is compile-time static by design.
>>
>> QOM is run-time dynamic by design. Some support for static definitions
>> has been grafted on since.
>>
>> We use QAPI type system escapes for QOM. Defeats QAPI introspection and
>> doc generation. We provide separate QOM introspection instead, which is
>> clumsier and less expressive. QOM documentation doesn't exist.
>
> But back to the original discussion about management tools,
> do we let upper layers tag their own arbitrary stuff in QOM objects?
We don't want management applications to add QOM properties for their
own purposes.
>>> Maybe what could be done is covering at least the static properties and
>>> then having key=value for the dynamic part (which should be the
>>> exception).
>>
>> To make this worthwhile, we'd have to replace dynamic QOM properties by
>> static ones when possible. Monumental task.
>
> I’m sure you are right, but it’s hard for me to evaluate, given how
> many ways there are to access an object. Naively, grepping for
> set_prop and for new_with_prop does not give me that many hits.
Look for object_property_add*(). Some 450 hits.
See also object_class_property_add(), grafted on in
commit 16bf7f522a2ff68993f80631ed86254c71eaf5d4
Author: Daniel P. Berrange <address@hidden>
Date: Tue Oct 13 13:37:46 2015 +0100
qom: Allow properties to be registered against classes
When there are many instances of a given class, registering
properties against the instance is wasteful of resources. The
majority of objects have a statically defined list of possible
properties, so most of the properties are easily registerable
against the class. Only those properties which are conditionally
registered at runtime need be recorded against the klass.
Registering properties against classes also makes it possible
to provide static introspection of QOM - currently introspection
is only possible after creating an instance of a class, which
severely limits its usefulness.
This impl only supports simple scalar properties. It does not
attempt to allow child object / link object properties against
the class. There are ways to support those too, but it would
make this patch more complicated, so it is left as an exercise
for the future.
There is no equivalent to object_property_del() provided, since
classes must be immutable once they are defined.
Signed-off-by: Daniel P. Berrange <address@hidden>
Signed-off-by: Andreas Färber <address@hidden>
>>>>>> - Relations, e.g. how we represent “contains”, “derives from”, “needs”,
>>>>>> “one of”, “one or several”, “attaches to”…
>>>>>> - States, e.g. how do we represent the machine configuration,
>>>>>> or the desired new disk setting
>>>>>> - Verbs, e.g. how we represent “add”, “connect”, “remove”, “find”,
>>>>>> “start”, “notify”, etc. and how we describe the kind of input they need.
>>>>>> - Possibly more subtle things like support for transactions, commit/rollback,
>>>>>> i.e. “I want to add connect a virtual nic to some host vf, but if anything
>>>>>> along the way fails, I’d like all the cleanup to happen automatically)
>>>>>
>>>>> This sounds like a different approach from our current QAPI command set
>>>>
>>>> Well, except for purposefully trying to use a different wording to avoid
>>>> the risk of getting your mind stuck in one of the particular existing
>>>> meta-languages in QEMU, the approach is not very different.
>>>
>>> I didn't necessarily mean relations/state/verbs, which obviously exist,
>>> but the examples that seemed to express things in a deliberately
>>> different way from what we have today.
>>>
>>>> - Transactions do not exist today that I know of, although we see
>>>> signs of them in discussions about the fact that this options destroys
>>>> that back end but that option does not.
>>>
>>> We have a 'transaction' QMP command, but they are not an integral part
>>> of the language. Considering the trouble to implement transactional
>>> commands, I suppose we don't even want it to be a fundamental part of
>>> the language.
>>>
>>>>> Does it actually provide more functionality, though?
>>>>
>>>> It’s not intended to provide more, but to require less to do the same thing.
>>>
>>> Though we always need to keep in mind that if requiring less for future
>>> additions requires a huge effort now, the investment may pay off only in
>>> a very distant future (if the abstraction we build even survives until
>>> then).
>>
>> Worse is better.
>>
>> http://dreamsongs.com/RiseOfWorseIsBetter.html
>
> You know that I positively hate this ;-)
It's been a tough lesson for me, too.
> Well, I guess we can expand the schema. #ILoveJSON.
Basing the QAPI language on JSON was a poor choice. Not sure that's
fixable at a reasonable cost.