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: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] /proc/xen/xenbus supports watch?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 21 Sep 2005 10:35:56 +0100
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Wed, 21 Sep 2005 09:28:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1127214064.2656.45.camel@xxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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.

If accesses from domU userspace are always communicated via the kernel device node, userspace gets no direct access to the transport page and so the kernel can ensure the page does not get corrupted. Also there's no need to hold the kernel lock for the duration of the user-space transaction if we mux multiple transactions onto a single page -- as independent transactions it is up to xenstored to deal with sync issues between them. We would need to hold the lock for short periods during the transaction (e.g., while accessing the shared transport page) but we would not be holding it continuously.

As for client handling of migration/restart -- it's an API issue that is independent of the underlying 'wire' transport.

 -- Keir


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