[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Interdomain comms



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.