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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 17 Sep 2005, at 09:26, Rusty Russell wrote:

> > How does two connections being 'logically separate' imply that it is
> > improper for them not to also be 'physically separate'? Multiplexing
> > multiple simultaneous connections/transactions onto a single 
> > underlying
> > page-level transport would seem fine to me!
> Um, multiplexing, like any feature, adds complexity: if we don't need
> it, don't do it.  <shrug>
That doesn't make it a 'hack'.

> We have a way of establishing new ringbuffers to talk to the store, we
> just currently assume one per domain.  Loosening that seems simpler and
> more robust than introducing a multiplexing layer, unless you two can
> see something I can't?
Multiplexing will require user-space reads/writes to be passed to the 
kernel rather than stuffing its own comms page directly. This has the 
advantage of being what we already do, and any performance 
disadvantages really don't matter.
On the xenstored side it ought simply to be a matter of picking a 
transaction or connection id out of the message to index into some kind 
of state table.
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.
Maybe there is a hidden complexity to muxing that we don't see? I guess 
save/restore needs some care because transaction-id state will be lost 
when we reconnect to a new xenstored.
 -- Keir


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