From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: latest USB code including Xenidc documentation Date: Fri, 16 Dec 2005 14:13:18 -0600 Message-ID: <43A31FDE.9080105@us.ibm.com> References: <1134751867.14087.27.camel@localhost.localdomain> <20051216170121.GF14690@granada.merseine.nu> <1134753831.19791.1.camel@localhost.localdomain> <20051216173859.GG14690@granada.merseine.nu> <1134759628.4801.42.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: <1134759628.4801.42.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: keir.fraser@cl.cam.ac.uk, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Harry Butterworth wrote: >I'm happy to do that for the USB driver if that's what people decide >they want but I'm reluctant to do it without people having first >considered the idea of having a higher level interdomain communication >API and thought about xenidc as a possible option. > > I think Muli's point (which I agree with) is that the question of a higher level interdomain communication API is orthagonal to the USB driver and that submitting the two at once makes it difficult to review because of sheer size. In fact, what I would really like to see is a before and after with the USB driver (one version that uses the current mechanism and uses xenidc). This would be a good way to evaluate how much complexity xenidc introduces/removes from the drivers. xenidc is a big decision because it means yet another rewrite of all the device drivers (we've gone through how many in the past year already :-)). Regards, Anthony Liguori > > >>Cheers, >>Muli >> >>