All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Martin Kletzander <mkletzan@redhat.com>,
	qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3] qmp: expose list of supported character device backends
Date: Tue, 11 Feb 2014 10:51:14 -0500	[thread overview]
Message-ID: <20140211105114.1912c198@redhat.com> (raw)
In-Reply-To: <52F94654.8080401@redhat.com>

On Mon, 10 Feb 2014 14:36:20 -0700
Eric Blake <eblake@redhat.com> wrote:

> On 02/10/2014 02:16 PM, Luiz Capitulino wrote:
> > On Sat,  1 Feb 2014 12:52:42 +0100
> > Martin Kletzander <mkletzan@redhat.com> wrote:
> > 
> >> Introduce 'query-chardev-backends' QMP command which lists all
> >> supported character device backends.
> >>
> >> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
> >> ---
> 
> >> +##
> >> +{ 'type': 'ChardevBackendInfo', 'data': {'name': 'str'} }
> > 
> > We already have ChardevBackend, it's an union though. I'm wondering if
> > you could change it to an enum and use it instead of plain 'str'?
> 
> Hmm, right now, the ChardevBackend union pre-dates when we added flat
> unions.  For flat unions, we can set a discriminator to be an enum type
> [1], at which point the code generator then validates that we cover all
> values of the enum in branches of the union; maybe it's worth
> retro-fitting simple unions to also take advantage of the additional
> coverage of the discriminator being an enum.
> 
> That is, right now, we have:
> 
> { 'union': 'ChardevBackend', 'data': { 'file'   : 'ChardevFile',
>                                        'serial' : 'ChardevHostdev',
> 
> and we also document in qapi-code-gen.txt that when using
> 'discriminator', you either have to have a base class (and the
> discriminator is a string-typed member of that base class), or the
> discriminator is {} because it is an anonymous union.  But I'm asking
> about yet another situation, of having a typed discriminator with no
> change to the wire format (no base class), something like:
> 
> { 'enum': 'ChardevBackendTypes', [ 'file', 'serial', ... ] }
> { 'union': 'ChardevBackend',
>   'discriminator': 'ChardevBackendTypes',
>   'data': { 'file': 'ChardevFile', ...
> 
> The benefit of such a plan is that we then have an introspectible enum
> of all possible backends known at compile time (ChardevBackendTypes),
> and the new addition in this patch becomes:
> 
> { 'type': 'ChardevBackendInfo',
>   'data': {'name', 'ChardevBackendTypes' } }
> 
> rather than raw 'str', while still allowing potential future additions
> of additional backend info.  Note that there would still be a difference
> between ChardevBackendTypes (an enum of all possible known types at
> compile time) vs. query-chardev-backends (a runtime list of the possible
> types that can be used for this particular machine, even if it is a
> subset of all possible ChardevBackendTypes).

Do you envision whether, by applying Martin's patch now, it would be
compatible to do what you suggest on top?

> 
> [1] actually, did those patches ever get applied, and we just missed
> documenting it in qapi-code-gen.txt, or are they still pending review?
> 
> > 
> >> +
> >> +##
> >> +# @query-chardev-backends:
> >> +#
> >> +# Returns information about character device backends.
> > 
> > Actually, it returns information about registered backends (registration
> > is done by register_char_driver_qapi(). So, I think it's good thing to
> > mention that this list is about available backends.
> 
> Again, it sounds like you want to emphasize an enum of all possible
> types (compile time, learned via introspection, whenever we get that)
> vs. registered backends (possibly a subset based on what libraries were
> used in building this qemu binary, and learned via the new QMP command).
> 

  parent reply	other threads:[~2014-02-11 15:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-01 11:52 [Qemu-devel] [PATCH v3] qmp: expose list of supported character device backends Martin Kletzander
2014-02-03 18:03 ` Eric Blake
2014-02-10 21:16 ` Luiz Capitulino
2014-02-10 21:36   ` Eric Blake
2014-02-11  8:32     ` Markus Armbruster
2014-02-11 13:14       ` Eric Blake
2014-02-11 15:51     ` Luiz Capitulino [this message]
2014-02-11 16:24       ` Eric Blake
2014-02-11 16:40 ` Luiz Capitulino

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=20140211105114.1912c198@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mkletzan@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.