All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH v4 0/8] qapi: Add support for aliases
Date: Wed, 27 Oct 2021 12:31:27 +0200	[thread overview]
Message-ID: <YXkqf37UWHnmUNUa@redhat.com> (raw)
In-Reply-To: <CAFn=p-ahKc+EjkUAPnSODQNY808z-qyc-DQUsseAobmB8A8NwA@mail.gmail.com>

Am 26.10.2021 um 23:23 hat John Snow geschrieben:
> On Fri, Sep 17, 2021 at 12:13 PM Kevin Wolf <kwolf@redhat.com> wrote:
> 
> > This series introduces alias definitions for QAPI object types (structs
> > and unions).
> >
> > This allows using the same QAPI type and visitor even when the syntax
> > has some variations between different external interfaces such as QMP
> > and the command line.
> >
> >
> I'm absurdly late to the party here, and I'm afraid my involvement may only
> stall your progress even further, but ...

I'm not sure if it's worth investing much of your time in this. After a
year of discussing implementation details, Markus decided that he
doesn't like the whole approach, so the series is probably dead in this
shape. Maybe parts of it (possibly even large parts) can be saved and
used in a modified approach, depending on how radically different the
new approach is.

Markus promised that he'll think of alternative approaches to solve the
problem. I'm waiting for that before I waste more time implementing
something else that is also dead from the start.

> can you fill me in on the slightly-less-higher-level details here?
> 
> I'm curious as to the nature of "has some variations" and how the aliases
> help alleviate them. Do you accomplish that compatibility by using
> different names for different fields of the struct?

> so e.g. x.foo can be used as an alias for x.bar, but both map ultimately
> onto 'x.foo'? Or does this series provide for some more fundamental
> mechanical changes to map one type onto another?

I would recommend reading the changes to docs/devel/qapi-code-gen.rst in
patch 7, which explain the implemented mechanism.

For -chardev, most of "some varations" are different names for the same
member of a struct, or nesting in QMP that you don't want to have on the
command line. I went through all cases in one of the last messages in
the v3 thread, but I think these are the two important categories of
cases.

The C types stay the same as they have always been, aliases just provide
an alternative way to specify the same thing in the input.

> > It also provides a new tool for evolving the schema while maintaining
> > backwards compatibility (possibly during a deprecation period).
> >
> > The first user is intended to be a QAPIfied -chardev command line
> > option, for which I'll send a separate series. A git tag is available
> > that contains both this series and the chardev changes that make use of
> > it:
> >
> >     https://repo.or.cz/qemu/kevin.git qapi-alias-chardev-v4

You may also want to have a look at this, and specifically
qapi/char.json, to see how I used aliases in practice.

Kevin



  reply	other threads:[~2021-10-27 10:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17 16:13 [PATCH v4 0/8] qapi: Add support for aliases Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 1/8] qapi: Add interfaces for alias support to Visitor Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 2/8] qapi: Remember alias definitions in qobject-input-visitor Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 3/8] qapi: Simplify full_name_nth() " Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 4/8] qapi: Store Error in StackObject.h for qobject-input-visitor Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 5/8] qapi: Apply aliases in qobject-input-visitor Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 6/8] qapi: Revert an accidental change from list to view object Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 7/8] qapi: Add support for aliases Kevin Wolf
2021-09-17 16:13 ` [PATCH v4 8/8] tests/qapi-schema: Test cases " Kevin Wolf
2021-10-01  9:28 ` [PATCH v4 0/8] qapi: Add support " Kevin Wolf
2021-10-26 21:23 ` John Snow
2021-10-27 10:31   ` Kevin Wolf [this message]
2021-10-27 15:34     ` John Snow

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=YXkqf37UWHnmUNUa@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.