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: Mon, 19 Sep 2005 09:54:50 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Christian.Limpach@xxxxxxxxxxxx
Delivery-date: Mon, 19 Sep 2005 08:47:43 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1127088661.23870.47.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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 19 Sep 2005, at 01:11, Rusty Russell wrote:

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.

Well, I can't disagree with this. :-) Whichever way we go we have to keep some per-handle state on users of the xenbus device, whether that's a transaction id or reference to a unique transport page. Either way we don't need to continuously hold the xenbus_lock (which is super gross).

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.

I wholeheartedly agree that restore should be equivalent to xenstored restart from the p.o.v. of the xenbus driver. That's how the block qnde net drivers already work. But it's orthogonal to whether we mux connections onto a single transport page.

 -- Keir


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