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?

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] /proc/xen/xenbus supports watch?
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Thu, 22 Sep 2005 12:07:32 +1000
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Thu, 22 Sep 2005 02:05:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <152436486e4a36af94a87ad6d40a768e@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <5d7aca9505090801025f3d5771@xxxxxxxxxxxxxx> <3d8eece205090803381b818f18@xxxxxxxxxxxxxx> <1126226609.25110.3.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091302422ac74f77@xxxxxxxxxxxxxx> <1126657264.7896.20.camel@xxxxxxxxxxxxxxxxxxxxx> <1126689530.4415.10.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091405555a2871fc@xxxxxxxxxxxxxx> <1126748390.12119.33.camel@xxxxxxxxxxxxxxxxxxxxx> <aad156145bec3bd706ef69c0e96341a7@xxxxxxxxxxxx> <1126945564.29203.116.camel@xxxxxxxxxxxxxxxxxxxxx> <bf4f0a8e8b96fd1ac2701daa78ca52c6@xxxxxxxxxxxx> <1127088661.23870.47.camel@xxxxxxxxxxxxxxxxxxxxx> <d7335251fd831e43f944d94e22da3878@xxxxxxxxxxxx> <1127214064.2656.45.camel@xxxxxxxxxxxxxxxxxxxxx> <152436486e4a36af94a87ad6d40a768e@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel