Il mer 15 gen 2020, 10:21 Markus Armbruster <arm...@redhat.com> 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 <berra...@redhat.com> > 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 <berra...@redhat.com> > Signed-off-by: Andreas Färber <afaer...@suse.de> > > >>>>>> - 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. > >
