Re: /proc/xen/xenbus supports watch?

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

On Thu, 2005-09-15 at 11:53 +0100, Keir Fraser wrote:
> On 15 Sep 2005, at 02:39, Rusty Russell wrote:
> 
> > we really do want separate connections
> > for each client: they're logically separate, so overloading them on one
> > transport is going to be a hack.
> 
> 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>

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?

Christian says:
> My main objections against multiple pages are:
> - setup/teardown overhead: we'll have to add messages to setup
>   and teardown a new connection

Which we already have, as above.

> - we have to maintain state about the connection in the daemon

But allowing multiple connections over one transport doesn't change
this.

> - save/restore becomes more complicated

Actually, I think it becomes simpler we simply force the device closed,
which should be handled by libxenstore just the same as a unix domain
socket closing on daemon restart, AFAICT.  So it has an appeal.

What was the reason for wanting multiple transactions per connection?
Changing the interface is going to be a PITA, so we should figure out if
we're going to need that soon...

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