Re: [Xen-devel] /proc/xen/xenbus supports watch?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 19 Sep 2005, at 01:11, Rusty Russell wrote:

> That's quoting a little out of context.  The current partial exposure 
> of
> the kernel's channel is a hack, since the current model is a 1:1 
> mapping
> between the transport and the connection.  The term hack is not a bad
> thing in itself, but it does accurately reflect that it's limited, as 
> in
> this case where we're asked to add watch support.
Well, I can't disagree with this. :-) Whichever way we go we have to 
keep some per-handle state on users of the xenbus device, whether 
that's a transaction id or reference to a unique transport page. Either 
way we don't need to continuously hold the xenbus_lock (which is super 
gross).
> > If we have multiple pages the client driver is complicated by 
> > reserving
> > user pages and creating grant references for them, and cleanly tearing
> > down and dealloc'ing grant references at the appropriate point(s). I
> > agree the daemon doesn't really get any more complicated, but I think
> > save/restore will need extra code, either in the domain0 tools or in
> > the guest os, to reconnect pages through to xenstored.
> No, this is the beauty of it: save/restore should be exactly to
> libxenstored as the restarting of store daemon; Christian and I have
> been vigorously debating semantics to get them the same (and I think
> we're close).  Then on save, the device simply closes; on restore, the
> library reconnects.
I wholeheartedly agree that restore should be equivalent to xenstored 
restart from the p.o.v. of the xenbus driver. That's how the block qnde 
net drivers already work. But it's orthogonal to whether we mux 
connections onto a single transport page.
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel