Re: [Qemu-devel] Writing a C library to generate qemu command lines and configuration files

[Markus Armbruster]

"Richard W.M. Jones" <address@hidden> writes:

> Firstly, is there such a thing already?  (libvirt doesn't count since
> it cannot generate -readconfig configuration files)

I'm not aware of no such thing.

> Well, I have written one.  It's in C and doesn't have any dependencies
> beyond the standard C library:
>
>   https://github.com/rwmjones/libguestfs/tree/max-disks/common/qemuopts
>
> It models command line parameters as either flags (eg. ‘-nodefconfig’),
> flags with a single argument (‘-name guest’), or flags taking a list
> (eg. ‘-drive file=foo,id=bar’ modeled as a list of strings).

See "option arguments values have become trees" below.

> I'm immediately aware that there are shortcomings with this approach
> (see below).  Is there a better model to use for qemu command line
> options that also allows -readconfig config files to be generated?
>
> Some of the more obvious problems:
>
> * I don't know if single flags can be translated into config files.

They can't.  -readconfig/-writeconfig cover only options implemented
with QemuOpts.

> * Config files treat the "id=.." parameter as special, eg:
>   ‘-drive file=foo,id=bar’ is translated to:
>
>   [drive "bar"]
>     file = "foo"

Yes.

> * There's no clear mapping between some command line parameters and
>   the config file, eg. ‘-m 2048 -kernel foo’ should be translated into:
>
>   [memory]
>     size = "2048"
>   [machine]
>     kernel = "foo"
>
>   but my library couldn't do that translation without a look-up table
>   that would duplicate the internals of qemu.

Yes.  Two problems:

* The configuration group name (the thing right after '[') by convention
  matches the command line option name.  Since the convention isn't
  enforced, screwups have crept in.  For instance, [boot-opts] matches
  -boot, and [memory] matches -m.  We suck.  Also plagues
  query-command-line-options.

* Even when it matches, it can only match the *unsugared* option name,
  not its various sugared forms.  For instance, -kernel ARG is sugar for
  -machine kernel=ARG.

> There are also unknown unknowns:
>
> * Is comma-quoting (ie. doubling any commas) sufficient?  Or are there
>   other forms of quoting?  A quick look at options parsing in qemu
>   doesn't show any.

A quick look at QemuOpts will at best confuse, and possibly deceive.

The beginnings of its replacement in util/keyval.c comes with a *gasp*
grammar.  It doesn't have all of QemuOpts bells & whistles, at least not
yet.  You might find it useful anyway.

To answer your question: you have to double comma after '=', or else it
terminates the value.  There is no other quoting.

> * From the point of view of a client generating command lines, is there
>   any significance to dotted names (eg. ‘-drive file.driver=ssh,...’)

Right now, you can still pretend dotted names are just names.

But option arguments have really become trees.  We've shoehorned them
into the existing command line syntax with dotted keys.  Design
discussion, if you're interested:

    Subject: Non-flat command line option argument syntax
    Message-ID: <address@hidden>
    https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00555.html

Implementation is the keyval.c mentioned above.

I'm not sure baking "option argument is a list of (key, string) pairs,
where both key and string are strings" into your library now is a good
idea.  Perhaps it would be better to embrace "option argument is a tree"
from the start.

In the longer run, I intend to make -readconfig (or its replacement)
accept JSON, because it supports trees directly, and is less badly
defined.

We might deprecate the Windows INI syntax then.

This might leave you with more questions.  Please don't hesitate to ask
me.