Re: Making QEMU easier for management tools and applications

[Christophe de Dinechin <dinechin@redhat.com>]

I started cutting some stuff out.

> On 14 Jan 2020, at 14:04, Markus Armbruster <armbru@redhat.com> wrote:
> 
> Prior art:
> 
>    Presentation
>    KVM Forum 2017: Towards a More Expressive and Introspectable QEMU
>    Command Line
>    https://www.youtube.com/watch?v=gtpOLQgnwug
>    https://www.linux-kvm.org/images/f/f2/Armbru-qapi-cmdline_1.pdf
> 
>    RFC patches
>    https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg00209.html
>    Message-Id: <20171002152552.27999-1-armbru@redhat.com>
>    https://repo.or.cz/qemu/armbru.git/shortlog/refs/heads/qapi-cmdline

Very useful, thanks.

> 
>> Compatibility is much harder, which is not the least because the
>> existing command line options are bad (primarily: using inconsistent
>> syntax).
> 
> Semantics are just as problematic.

Yes, but often you can leverage something (e.g. JSON, XML, etc)

We could decide that the new QAPI language is a custom implementation
of Python ;-) Or more seriously, we could have some part of the JSON
schema that are “escapes” to C code that we put in some generated file.
I used {{ }} below for this escape, in which case the semantics would be
that of C plus some specific macros we insert in it.

{ 'option': '--add-fd',
 'data': { 'fd': 'int', 'set': 'int', '*opaque': 'str' },
 'help': [
"-add-fd fd=fd,set=set[,opaque=opaque]",
"                Add 'fd' to fd 'set'”] 
 ‘validate’ : {{
    error_if(QOPT.fd < 0, “fd option cannot be negative”);
    error_if(QOPT.fd <= STDERR_FILENO, “fd cannot be a standard I/O stream”);
 }},
 ‘exec’ : {{
    if (do_add_fd(QOPT.fd, QOPT.fset, QOPT.opaque) < 0) {
        exit(1);
    }
 }},

I’m not necessarily saying this is a good idea, mind you.

> 
> You mean the qemu-options.hx.  qemu-options.def is generated from it.

Oh, I had missed that, thanks.

>>> or build configuration (there is a hint of the connection between
>>> the two in the option ‘if’ member in the .json files).
> 
> I'm not sure what exactly you have in mind for build configuration.

I meant what you pointed out wrt. options, that this “language” needs to
know about the qemu configuration. There is ‘if’ today, you pointed
out arch-specific for options. But the configuration itself is yet
another “language” with its own semantics… which JSON knows
nothing about.

> 
>>> In other words, the language I have in mind would be something
>>> that I could auto-generate from, say, the current qapi-schema.json
>>> and the qemu-options.def. Maybe in the end, that would be simply
>>> by having qemu-options.def being used to build qemu-options.json,
>>> and then add the relevant entries in qemu-options.json. Maybe
>>> there is a better way.
>> 
>> I would rather say that .def should go away and its content should
>> be converted to a JSON schema that becomes the new source format rather
>> than an intermediate generated file. There is nothing in .def files that
>> couldn't be represented in the schema.
> 
> Yes.

Agreed too. The meta-schema would need to be extended.

>> 
>> To a certain degree, QAPI does just that, by supporting different data
>> types for options. If necessary, I'm sure the type system could be
>> extended, but it's not clear to me to which degree we actually need
>> this.
> 
> QAPI is much more expressive than qemu-options.hx.  All the latter can
> do is "has option argument" and "option is arch-specific".  QAPI lets
> you specify an option argument's structure, and supports compile-time
> conditionals.  It can't do things like "must specify either argument A
> or B", or "numeric argument C must not exceed argument D", or "multiple
> options combine vs. last one wins".  Mostly because "it’s already
> complicated enough as is".

Understood.


>> 
>> We could. But is it actually worth inventing a new programming language?
>> I think this is something that should be done in C code even in the
>> future. I think what we're looking for is a way to describe interfaces,
>> not implementations.
> 
> Sane sugar can be described declaratively as macro expansion.
> 
> Less than sane sugar takes code.
> 
> Desugaring in code promotes (accidental) abandonment of sanity.
> 
> That said, we have to keep things simple to succeed.  Declarative
> desugaring seems beyond our reach.

Well, “keeping things simple” is a complicated thing.

> 
>> Even just for adding more sophisticated constraints, like in the example
>> above that maxmem >= size, it's questionable whether doing this in the
>> schema provides enough value for actually implementing it there.
> 
> Yes.

If we do it, yes. If we delegate to an existing language (I showed C above),
maybe it adds clarity without too much of an additional cost.

> 
>>>> I think the only thing in this list that can't obviously be covered
>>>> easily by QAPI is QOM. Or rather, it's covered by passing through
>>>> key=value lists without describing their structure
>>> 
>>> That’s close enough to me. (In my mind, that part was already “done”
>>> by QAPI, even if in the convoluted way you describe)
>> 
>> That's not really close enough. If you are happy with this level of
>> abstraction, you can define any command line option to be either a flag
>> or take a string as its argument and be done. This is obviously not very
>> helpful because it says nothing about the structure of that string.
> 
> Similar to all QMP commands taking a single 'any' argument.

Hmmm, I guess I have not understood what you meant by
"QOM could not be covered easily by QAPI" then.

We don’t want the QAPI to let arbitrary fields of a QOM object
be modified, do we?

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?


> 
>>                                                                    In
>> 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.

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.

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.


> 
> 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?


> 
>> 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.


> 
>>>>> - 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 ;-)

Well, I guess we can expand the schema. #ILoveJSON.


Thanks
Christophe