All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"John Snow" <jsnow@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: QAPI sync meeting
Date: Fri, 08 Oct 2021 12:06:23 +0200	[thread overview]
Message-ID: <87bl3z96g0.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <3abc4e8e-5657-14bb-ba89-5b7669c01201@redhat.com> (Paolo Bonzini's message of "Thu, 7 Oct 2021 12:23:58 +0200")

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 07/10/21 12:01, Kevin Wolf wrote:
>>    * -chardev: I have patches that QAPIfy the option based on
>> aliases,
>>      getting rid of the old handwritten parser that is inconsistent with
>>      QMP in non-obvious ways and replacing it with translation to QMP
>>      (both using aliases and a little C code) that makes the differences
>>      obvious.
>>      First posted in November 2020, more details in the cover
>> letter:
>>      https://patchew.org/QEMU/20201112175905.404472-1-kwolf@redhat.com/
>>      Later versions (not yet posted as a series because I'm waiting
>> for
>>      aliases) also make -chardev accept JSON syntax, which is what
>>      libvirt really wants to use.
>
> I'm still not sure about this...  It's an awful lot of code if the
> aliases are only used by -chardev,

We might use them for replacing other ad hoc parsers.  We have a bunch,
but -chardev's one is perhaps the worst one.  Whether aliases could be
useful for replacing others is not yet clear.

I initially hoped that they could help us clean up QMP some, but further
(and sadly much later) thought led me to obstacles.

>                                    and I'd rather use
> -object/object-add for chardevs if that's at all possible.

How far are we from making -object the preferred machine-friendly
interface for creating character devices?



  parent reply	other threads:[~2021-10-08 10:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27 16:55 QAPI sync meeting John Snow
2021-09-28 11:38 ` Marc-André Lureau
2021-09-28 13:14 ` Kevin Wolf
2021-09-28 13:53 ` Daniel P. Berrangé
2021-09-28 17:43   ` John Snow
2021-09-29 12:18     ` Markus Armbruster
2021-09-30  0:49       ` John Snow
2021-10-07 10:01       ` Kevin Wolf
2021-10-07 10:23         ` Paolo Bonzini
2021-10-07 12:53           ` Kevin Wolf
2021-10-07 13:02             ` Daniel P. Berrangé
2021-10-08 10:06           ` Markus Armbruster [this message]
2021-10-08 17:07             ` Paolo Bonzini
2021-10-07 12:43         ` John Snow
2021-09-28 15:19 ` Paolo Bonzini
2021-09-29 13:42 ` Damien Hedde
2021-09-30  0:31   ` 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=87bl3z96g0.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@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.