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] Re: Interdomain comms

To: andrew.warfield@xxxxxxxxxxxx
Subject: Re: [Xen-devel] Re: Interdomain comms
From: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 10 May 2005 17:42:25 +0100
Cc: Eric Van Hensbergen <ericvh@xxxxxxxxx>, Mike Wray <mike.wray@xxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Ronald G. Minnich" <rminnich@xxxxxxxx>, Eric Van Hensbergen <ericvh@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 10 May 2005 16:42:11 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <eacc82a405051008261f21147@xxxxxxxxxxxxxx>
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: <0BAE938A1E68534E928747B9B46A759A6CF3AC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1115486227.4082.70.camel@localhost> <a4e6962a050507142932654a5e@xxxxxxxxxxxxxx> <1115503861.4460.2.camel@localhost> <a4e6962a050507175754700dc8@xxxxxxxxxxxxxx> <eacc82a4050508011979bda457@xxxxxxxxxxxxxx> <42807150.3030907@xxxxxx> <eacc82a405051003094d84c011@xxxxxxxxxxxxxx> <1115736719.11547.132.camel@localhost> <eacc82a405051008243195164c@xxxxxxxxxxxxxx> <eacc82a405051008261f21147@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2005-05-10 at 16:26 +0100, Andrew Warfield wrote:

> I think we are all keen to move in the direction of having no xend but
> rather a small set of single purpose daemons that handle specific
> tasks and map well on to the emerging security primitives.

Yep.

> Connection setup this way does map on to the connect/listen semantics
> that Mike has been advocating.  For example, on a request to add a new
> frontend, the backend driver will create a simple state machine for
> the new device channel and assign an unbound event channel to it.  It
> will then move out of this (unbound) "listening" state when the front
> end connects to the event channel and sends the first notification.

The above description happens to fit inside my endpoint_create call too.

I think the significant constraints in this area are that the choice of
connect/listen semantics must be compatible with the introduction
mechanism and the security requirements.

With my API I assumed a symmetrical connection process where both ends
created an endpoint for the same address and the IDC implementation did
the work of binding them together.  I didn't give any thought to the
implications for the introduction mechanism or the security requirements
or consider any other options so I'm not particularly attached to this
aspect of my proposal.  I was primarily trying to communicate the buffer
abstractions.


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

<Prev in Thread] Current Thread [Next in Thread>