From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Butterworth Subject: Re: Re: Interdomain comms Date: Tue, 10 May 2005 17:42:25 +0100 Message-ID: <1115743345.32540.160.camel@localhost> References: <0BAE938A1E68534E928747B9B46A759A6CF3AC@EXCNYSM0A1AH.nysemail.nyenet> <1115486227.4082.70.camel@localhost> <1115503861.4460.2.camel@localhost> <42807150.3030907@hp.com> <1115736719.11547.132.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: andrew.warfield@cl.cam.ac.uk Cc: Eric Van Hensbergen , Mike Wray , xen-devel@lists.xensource.com, "Ronald G. Minnich" , Eric Van Hensbergen List-Id: xen-devel@lists.xenproject.org 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.