From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: /proc/xen/xenbus supports watch?
Date: Thu, 22 Sep 2005 12:07:32 +1000
Message-ID: <1127354853.7567.6.camel@localhost.localdomain>
References: <5d7aca9505090801025f3d5771@mail.gmail.com>
	<3d8eece205090803381b818f18@mail.gmail.com>
	<1126226609.25110.3.camel@localhost.localdomain>
	<3d8eece205091302422ac74f77@mail.gmail.com>
	<1126657264.7896.20.camel@localhost.localdomain>
	<1126689530.4415.10.camel@localhost.localdomain>
	<3d8eece205091405555a2871fc@mail.gmail.com>
	<1126748390.12119.33.camel@localhost.localdomain>
	<aad156145bec3bd706ef69c0e96341a7@cl.cam.ac.uk>
	<1126945564.29203.116.camel@localhost.localdomain>
	<bf4f0a8e8b96fd1ac2701daa78ca52c6@cl.cam.ac.uk>
	<1127088661.23870.47.camel@localhost.localdomain>
	<d7335251fd831e43f944d94e22da3878@cl.cam.ac.uk>
	<1127214064.2656.45.camel@localhost.localdomain>
	<152436486e4a36af94a87ad6d40a768e@cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <152436486e4a36af94a87ad6d40a768e@cl.cam.ac.uk>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel List <xen-devel@lists.xensource.com>, Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
List-Id: xen-devel@lists.xenproject.org

On Wed, 2005-09-21 at 10:35 +0100, Keir Fraser wrote:
> On 20 Sep 2005, at 12:01, Rusty Russell wrote:
> 
> > By providing a kernel device node we
> > make it look exactly like talking through a socket, so libxenstore is
> > basically unchanged.  By each open using a separate page to talk to
> > xenstored, we don't have to hold the kernel lock, nor worry about tool
> > errors/crashes screwing the kernel's store page.  xenstored restarts 
> > are
> > transparent.  On migration, we can simply force close (unmap page,
> > return EBADF), which libxestore can treat exactly like the xenstored
> > restart case with sockets, reconnect and re-xmit.
> 
> None of this really adds weight for or against muxing versus 
> page-per-transaction.

Exactly!  So you would have me implement multiplexing code in the
kernel, demultiplexing code in the daemon, checking code in the kernel
to make sure we don't corrupt the shared comms channel, for no reason.

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