[Xen-devel] [Fwd: Re: Interdomain comms]

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

oops, forgot to copy the list on this reply.

--- Begin Message ---

To:	Mike Wray <mike.wray@xxxxxx>
Subject:	Re: Interdomain comms
From:	Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date:	Fri, 06 May 2005 15:57:35 +0100
In-reply-to:	<427B723A.6030006@xxxxxx>
References:	<0BAE938A1E68534E928747B9B46A759A6CF3AC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1115325448.12082.79.camel@localhost> <427B20B9.1010101@xxxxxx> <1115381693.18929.159.camel@localhost> <427B723A.6030006@xxxxxx>

On Fri, 2005-05-06 at 14:33 +0100, Mike Wray wrote:
> Harry Butterworth wrote:
> > What exactly were the issues with the socket-like proposal?
> 
> The main objection was from Keir, he thought it was 'overkill'.

Given that the ratio of IDC API clients to IDC API implementations is
many to one I think it makes sense to invest in the IDC API
implementation to save effort in the clients.

Also, having smaller clients and more common code will make it easier to
introduce security features and implement performance optimisations.

Also, with a simpler API, there is less missing documentation ;-)

Seems like a no-brainer to me.  Maybe Keir has more specific objections?

> I agree with that. I've attached what I sent out as the socket proposal.
> Thinking about it though, I don't really see why the api can't use
> the standard linux kernel 'struct sock' for the endpoints and 'struct sk_buff'
> for the data. These are both very flexible structs and can hide a lot of
> stuff. You need some struct for the addressing.
> 
> The sk_buffs could be allocated out of the ring messages to avoid
> copying.

Ideally, I think the API should be self-contained, independent of Linux
and not a derived work because equivalent function is going to be
required for other paravirtualized operating systems and it would be
good to be able to have a common code base.

The extra features in my API are all there for a reason: transactions
with a request and response phase are convenient for the clients; the
three states for the connection allow bracketing of changes in the
availability of the resources that are of relevance to a specific client
without global coordination; I specifically included the guarantees
required to cope with stale communications; my sketch was expressed
independent of the existing linux code and my API is sufficiently
different from the well known sockets API that people won't get the two
APIs confused.

Again, this is just a sketch.  If I thought about it I might want to
change it significantly.

I really must force myself to get back to the USB stuff now.

Harry.

--- End Message ---

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