qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/3] usb-redir: Call qemu_chr_guest_open/close
Date: Mon, 08 Aug 2011 15:03:48 +0200	[thread overview]
Message-ID: <4E3FDEB4.3060104@redhat.com> (raw)
In-Reply-To: <4E3FDBF0.5030403@codemonkey.ws>

Hi,

On 08/08/2011 02:52 PM, Anthony Liguori wrote:
> On 08/08/2011 03:01 AM, Hans de Goede wrote:

<snip>

>>> So after my char-flow changes, you won't be allowed to set handlers
>>> unless you've called open.
>>>
>>
>> Why not do it the other way around? So don't allow open until the
>> handlers are set. My reasoning
>> behind this is that eventually we will want to have a struct describing
>> a pipe endpoint, which
>> will contain handlers (by then identical for both sides) and besides the
>> struct a priv / user_data
>> pointer which will get passed by the handlers when called.
>>
>> Then we will have a chardev_create or pipe_create call which will take a
>> struct + user data ptr
>> for both ends (so twice). This matches what currently our set handlers
>> call does. But I would
>> expect the open to come after the creation of the pipe.
>
> BTW, I'm 90% of the way there in my queue:
>
> http://repo.or.cz/w/qemu/aliguori.git/shortlog/refs/heads/char-flow
>
> My plan is to have a CharPipe structure that has two CharDriverStates embedded in it. The backend/frontends need to attach themselves to the CharDriverState. I see that as open().
>

So the attaching will cause the other end to see an open() (if the
other end is already attached) ? Or will their still be a separate
send open event call? And should that call be made before or after
the attach?

Regards,

Hans

  reply	other threads:[~2011-08-08 13:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-07 13:21 [Qemu-devel] [PATCH 1/3] spice-qemu-char: Generate chardev open/close events Hans de Goede
2011-08-07 13:21 ` [Qemu-devel] [PATCH 2/3] usb-redir: Call qemu_chr_guest_open/close Hans de Goede
2011-08-07 15:52   ` Anthony Liguori
2011-08-07 17:41     ` Hans de Goede
2011-08-07 21:30       ` Anthony Liguori
2011-08-08  8:01         ` Hans de Goede
2011-08-08 12:52           ` Anthony Liguori
2011-08-08 13:03             ` Hans de Goede [this message]
2011-08-08 13:08               ` Anthony Liguori
2011-08-07 13:21 ` [Qemu-devel] [PATCH 3/3] usb-redir: Device disconnect + re-connect robustness fixes Hans de Goede
2011-08-07 15:52 ` [Qemu-devel] [PATCH 1/3] spice-qemu-char: Generate chardev open/close events Anthony Liguori
2011-08-07 17:39   ` Hans de Goede

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=4E3FDEB4.3060104@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=kraxel@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 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).