From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nivedita Singhvi Subject: Re: [Fwd: Re: Interdomain comms] Date: Fri, 06 May 2005 10:26:09 -0700 Message-ID: <427BA8B1.40106@us.ibm.com> References: <1115391567.13912.41.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1115391567.13912.41.camel@localhost> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Harry Butterworth Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Harry Butterworth wrote: >>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' struct sock is very, very, large - and we need to be much more memory-sensitive than mainline Linux. That does seem to me to be overkill. >>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. You can do this with smaller subsets of that struct, certainly. > 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. Good point. > 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. It will be cleaner to build an alternative virtual infrastructure underneath, too. thanks, Nivedita