All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	qemu block <qemu-block@nongnu.org>
Subject: Re: downstream extensions
Date: Thu, 10 Feb 2022 08:48:23 +0100	[thread overview]
Message-ID: <874k57duwo.fsf@pond.sub.org> (raw)
In-Reply-To: <5c95f20c-df30-9d24-0e1b-f82f4d5a798e@virtuozzo.com> (Vladimir Sementsov-Ogievskiy's message of "Wed, 9 Feb 2022 15:33:04 +0300")

Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:

> Hi all!
>
> We declare a kind of __com.redhat_drive-mirror syntax for downstream extensions of QAPI.
>
> That's inconvenient:
>
> Assume I want to merge now my keep-dirty option for Qcow2 driver "[PATCH v2 0/2] qcow2: add keep-dirty open option" to our downstream. To avoid possible conflicts with upstream in future, I should now call it __com.virtuozzo_keep-dirty. Not saying about this being too awkward, there is a real problem:
>
> I want to support dot-object-notation syntax, i.e. something like
>
> qemu-img check --image-opts driver=qcow2,keep-dirty=true,file.filename=img.qcow2
>
> And this way, a period inside a name looks ambiguous, as it looks like subproperty of "__com" property.

The downstream extension prefix predates dotted keys.  Their combination
is less than ideal, as you point out, but it's not actually ambiguous:

Consider this grammar:

    key               = key-fragment { '.' key-fragment }
    key-fragment      = [ downstream_prefix ] / [^=,.]+ /
    downstream_prefix = '__' rfqdn '_'
    rfqdn             = / [A-Za-z0-9.-] /

When a key-fragment starts with '__', it has a downstream prefix, which
extends to the next '_'.

parse_qapi_name() implements this, and keyval.c uses it.

The grammar in keyval.c neglects to cover the downstream prefix.  I'll
fix it.

> I now tested, it still works somehow, and test from my series passes with
>
>  keep_dirty_opts="driver=qcow2,__com.virtuozzo_keep-dirty=true,file.filename=$TEST_IMG"

qemu-img --image-opts still uses QemuOpts.  I don't remember more about
how it parses dotted keys other than "it's complicated", but downstream
prefixes not working would be a bug.

> But anyway, it looks ambiguous, and I don't want to use it and share with my colleagues.
>
> In past, I used x-vz- prefix for downstream names (before I heard about __RFQDN_ notation declared in QAPI spec), that was more convenient. But still, that is not correct..
>
> I now think to use just __vz_ prefix. Such name will never appear upstream, and unlikely to be used by Rhel downstream which is our base. And I don't care about any other downstreams.
>
>
> Any thoughts? Should we change the recommendations somehow? I think allowing dots in names in the object model is a bad idea.

Maybe, but that boat sailed long ago.

QAPI's downstream prefix was designed this way to let organizations
extend the schema without having to worry about clashes regardless of
how things get rebased or remixed.  That's a feature.

It reuses an existing registry of organization names: domain names.  Not
needing our own registry is also a feature.

Of course, nothing can stop you from putting something other than RFQDN
between __ and _.  I'd recommend not to.

We could add a revised downstream prefix syntax, and deprecate the first
one.  To me, that feels like more trouble and complexity than it's
worth.  I could be wrong.  Happy to read proposals.



      reply	other threads:[~2022-02-10  8:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09 12:33 downstream extensions Vladimir Sementsov-Ogievskiy
2022-02-10  7:48 ` Markus Armbruster [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874k57duwo.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.