From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nivedita Singhvi Subject: Re: Re: USB virt status Date: Fri, 04 Nov 2005 20:08:09 -0800 Message-ID: <436C3029.5040902@comcast.net> References: <1130690595.28174.13.camel@localhost> <200511041725.11451.mark.williamson@cl.cam.ac.uk> <1131130680.3019.87.camel@localhost.localdomain> <200511050050.58120.mark.williamson@cl.cam.ac.uk> <1131157306.4740.65.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1131157306.4740.65.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, Mark Williamson List-Id: xen-devel@lists.xenproject.org Harry Butterworth wrote: > On Sat, 2005-11-05 at 00:50 +0000, Mark Williamson wrote: >>Yes, right now I'm working with Xenstore too. The updates I mentioned are >>supposed to tackle this problem by providing a better API, automating the >>channel setup state machine for the majority of users (i.e. all devices). I >>believe a some of this code is fully completed and awaiting push to the main >>tree once it's been reviewed by a few people. Hi Mark, I didn't see the original email that Harry quoted, but could you elaborate on that? Are you proposing a new API? Why only a few people? Any reason not on the list? Rusty had asked a question regarding what's in 3.0: http://marc.theaimsgroup.com/?l=xen-devel&m=113038760216447&w=2 and I guess I'll second that.. >>I really would have liked to see a more abstract interface to communications, >>such as the one you propose. However, it is not going to happen for the 3.0 >>release and that's when the team promised the interfaces will be frozen. If >>it can't be compatible with the existing interfaces, that's going to make it >>much less likely that anyone will update the existing drivers and then >>maintain two separate interdomain interfaces for each. >> >>I think the project is likely to follow the path of least resistance and go >>with a "xenstore connection setup library" that replaces most of the >>duplicate code but retain the old datapath API. I get the impression this >>decision has been taken already. Any reason for this to not be shared on xen-devel? thanks, Nivedita