[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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'? Multiplexingmultiple simultaneous connections/transactions onto a single underlyingpage-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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |