Re: [Qemu-devel] [PATCH 2/3] usb-redir: Call qemu_chr_guest_open/close

[Anthony Liguori <anthony@codemonkey.ws>]

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:
>
> <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?

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
>