[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [Qemu-block] Non-flat command line option argument syntax
Date: Fri, 24 Feb 2017 17:04:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

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


Dotted keys parse this as a reference to member __com's member

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]