From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqPZj-0001WV-1U for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:09:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqPZf-0002Dv-R4 for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:08:59 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:53299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqPZf-0002Di-O7 for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:08:55 -0400 Received: by ywf9 with SMTP id 9so294539ywf.4 for ; Mon, 08 Aug 2011 06:08:55 -0700 (PDT) Message-ID: <4E3FDFE4.9070301@codemonkey.ws> Date: Mon, 08 Aug 2011 08:08:52 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1312723284-7549-1-git-send-email-hdegoede@redhat.com> <1312723284-7549-2-git-send-email-hdegoede@redhat.com> <4E3EB4CE.8030201@codemonkey.ws> <4E3ECE4C.10805@redhat.com> <4E3F03E3.1080706@codemonkey.ws> <4E3F97F2.2050100@redhat.com> <4E3FDBF0.5030403@codemonkey.ws> <4E3FDEB4.3060104@redhat.com> In-Reply-To: <4E3FDEB4.3060104@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/3] usb-redir: Call qemu_chr_guest_open/close List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: Gerd Hoffmann , qemu-devel@nongnu.org On 08/08/2011 08:03 AM, Hans de Goede wrote: > Hi, > > On 08/08/2011 02:52 PM, Anthony Liguori wrote: >> On 08/08/2011 03:01 AM, Hans de Goede wrote: > > > >>>> 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? Doing an open() will result in an open event being generated. Neither side should ever be directly involved in sending open/close events. Regards, Anthony Liguori > > Regards, > > Hans >