Re: [Qemu-devel] Non-flat command line option argument syntax

[Markus Armbruster]

Markus Armbruster <address@hidden> writes:

[...]
> === Dotted keys ===
>
> One sufficiently powerful syntax extension already exists: the dotted
> key convention.  It's syntactically unambiguous only when none of the
> KEYs involved contains '.'  To adopt it across the board, we'd have to
> outlaw '.' in KEYs.  QAPI outlaws '.' already,

*Except* in __RFQDN_ prefixes.

Say example.com needs to add a downstream extension to block driver
"raw".  Following QAPI rules, they add to to struct BlockdevOptionsRaw a
new optional member:

    '*__com.example_medium-rare': 'bool'

On the command line, this looks like

    -blockdev 
node-name=foo,driver=raw,__com.example_medium-rare=on,file.driver=file,file.filename=foo.img

Dotted keys parse this as a reference to member __com's member
example_medium-rare.

Possible solutions:

(a) Outlaw domain names with '_'.  If KEY starts with "__", everything
    up to the third '_' is an __RFQDN_ prefix.

(b) Outlaw '_' in the name part that follows __RFQDN_.  If KEY starts
    with "__", everything up to the last '_' is an __RFQDN_ prefix.

(c) Your bright idea.

I think (b) should do.  QAPI prefers '-' over '_' for new member names
anyway.

>                                                but we have a bunch of
> QOM properties names with '.'.  We'd have to rename at least the ones
> that need to be accessible in -object.
>
> Dotted keys can't express member names that look like integers.  We'd
> have to outlaw them at least for the objects that are accessible on the
> command line.  Once again, QAPI outlaws such names already.  QOM is
> anarchy when it comes to names, however.
>
> The way dotted keys do arrays is inconsistent with how QOM's automatic
> arrayification (commit 3396590) do them: foo.0 vs. foo[0].  Backward
> compatibility makes changing the dotted key convention awkward.  Perhaps
> we can still change QOM.

[...]