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
