From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Butterworth Subject: [Fwd: Re: Interdomain comms] Date: Fri, 06 May 2005 15:59:27 +0100 Message-ID: <1115391567.13912.41.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-DPRtEeAJujxM4fFgOqar" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --=-DPRtEeAJujxM4fFgOqar Content-Type: text/plain Content-Transfer-Encoding: 7bit oops, forgot to copy the list on this reply. --=-DPRtEeAJujxM4fFgOqar Content-Disposition: inline Content-Description: Forwarded message - Re: Interdomain comms Content-Type: message/rfc822 Subject: Re: Interdomain comms From: Harry Butterworth To: Mike Wray In-Reply-To: <427B723A.6030006@hp.com> References: <0BAE938A1E68534E928747B9B46A759A6CF3AC@EXCNYSM0A1AH.nysemail.nyenet> <1115325448.12082.79.camel@localhost> <427B20B9.1010101@hp.com> <1115381693.18929.159.camel@localhost> <427B723A.6030006@hp.com> Content-Type: text/plain Date: Fri, 06 May 2005 15:57:35 +0100 Message-Id: <1115391456.13912.40.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit 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. --=-DPRtEeAJujxM4fFgOqar Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --=-DPRtEeAJujxM4fFgOqar--