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

[Richard W.M. Jones]

On Tue, May 02, 2017 at 04:28:52PM +0200, Markus Armbruster wrote:
> > * 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.

Hmm, is that really right?  It seems to me that any comma must be
doubled.  For example:

$ qemu-system-x86_64 -name foo,bar -writeconfig - -hda die
qemu-system-x86_64: -name foo,bar: Invalid parameter 'bar'

$ qemu-system-x86_64 -name foo,,bar -writeconfig - -hda die
# qemu config file

[name]
  guest = "foo,bar"

qemu-system-x86_64: -hda die: Could not open 'die': No such file or directory

--- Or:

$ qemu-system-x86_64 -drive file=foo,,bar -writeconfig - 
# qemu config file

[drive]
  file = "foo,bar"

qemu-system-x86_64: -drive file=foo,,bar: Could not open 'foo,bar': No such 
file or directory

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

OK, I'll think about that.

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

And JSON actually thinks about quoting too :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org