WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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


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