qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Kővágó Zoltán" <dirty.ice.hu@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH v2] qapi for audio backends
Date: Mon, 08 Jun 2015 09:42:25 +0200	[thread overview]
Message-ID: <1433749345.5046.22.camel@redhat.com> (raw)
In-Reply-To: <5571AA1B.8060800@gmail.com>

On Fr, 2015-06-05 at 15:54 +0200, Kővágó Zoltán wrote:
> Hi,
> 
> 2015-06-05 12:57 keltezéssel, Gerd Hoffmann írta:
> >> Yeah, I've already hit a problem. The opts_visitor doesn't really handle
> >> nested structs (it just flattens it into a single, non hierarchic
> >> namespace), which is a problem because of the input and output options.
> >> First I need to make them required (the in and out in Audiodev) if I
> >> want the current visitor to visit them at all, but it's still not enough.
> >
> > I think we should improve the visitor instead of making in & out
> > mandatory just because the current implementation (which simply
> > implements the stuff needed for Netdev) can't handle it.
> 
> It's not that simple I think. The visit_optional only receives a field 
> name, but no info about the type of the field, but it has to decide if 
> it wants the field using only this info. So sort of hacking an if 
> (strcmp(name, "in") == 0 || strcmp(name, "out") == 0) ... into the 
> option visitor code, the only way is probably to add a type parameter to 
> visit_optional (struct/union/uint32/whatever) and in the opts visitor if 
> type is struct or union, force visiting it. Is it ok?

Thinking about this a bit more, I suspect it becomes tricky when it
comes to allocation.  We want allocate *in and *out only in case there
are actually parameters for it on the command line.

But I think we have to pass something down to the struct visitor (given
how visitors are designed).  So allocate, pass down, then free again in
case nothing was filled?  How do we figure nothing was filled, in the
generic visit_optional function?

Of course we can avoid this complexity by simply allocating *in and *out
unconditionally, but then it is pointless to make it optional in the
first place.  So maybe it is better to go with your original idea to
just make them mandatory (and all elements inside optional).

cheers,
  Gerd

      reply	other threads:[~2015-06-08  7:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-04 13:39 [Qemu-devel] [RFC PATCH v2] qapi for audio backends Kővágó, Zoltán
2015-06-04 15:30 ` Gerd Hoffmann
2015-06-04 22:08   ` Kővágó Zoltán
2015-06-05 10:57     ` Gerd Hoffmann
2015-06-05 13:54       ` Kővágó Zoltán
2015-06-08  7:42         ` Gerd Hoffmann [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=1433749345.5046.22.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=dirty.ice.hu@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).