Re: /proc/xen/xenbus supports watch?

[Rusty Russell <rusty@rustcorp.com.au>]

On Sat, 2005-09-17 at 09:33 +0100, Keir Fraser wrote:
> 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'.

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.

> > 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.

No, I'm proposing we keep the device in the domU kernel exactly as now,
but rather than sharing the same page, use separate pages.  This means
we don't have to share the same lock or worry about userspace messing
up, etc.

> 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.

Sure, I can write multiplexing and demultiplexing code for the store
daemon, separate the data structures, duplicate that code in libxenstore
and xenbus.  But AFAICT it's code which simply doesn't need to exist.

> 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.

So, in summary: separating the concept of transport from connection is
possible, but I don't think it actually buys us anything except another
layer of indirection.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman