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/
Home Products Support Community News


Re: [Xen-devel] watches not working from domU userspace

To: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Subject: Re: [Xen-devel] watches not working from domU userspace
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 7 Jan 2006 10:49:41 +0000
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 07 Jan 2006 11:06:14 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA95C29D57188841ABB072EA7357C00D0A9855DC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <CA95C29D57188841ABB072EA7357C00D0A9855DC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 7 Jan 2006, at 10:06, Cihula, Joseph wrote:

The connection sud-id approach also has the option of keeping the same
suspend behavior since that only depends on snooping the communication
and not maintaining any state (other than the mutex).  And if drivers
use the sub-ids, I think that more transaction and watch bookkeeping
could be removed from xenbus.  And the grant table change to
XS_INTRODUCE that I mentioned works either way.

Are there additional benefits to the grants approach besides just
removing xenbus from the communication path?

Yes, I think maybe you are right. I missed that the connection id can conveniently be used to demux watch events. That given, I think piggybacking connections is the way to go after all.

Reusing the request_id as a conn_id should work fine, since all current clients just set that field to zero. Do you intend to introduce new commands like XS_CREATE_CONNECTION / XS_DESTROY_CONNECTION? I think that those ought to be executable only by the root connection (connection 0).

 -- Keir

Xen-devel mailing list