From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Butterworth Subject: Re: latest USB code including Xenidc documentation Date: Mon, 19 Dec 2005 10:54:11 +0000 Message-ID: <1134989651.5070.6.camel@localhost> 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> <20051217081617.GK14690@granada.merseine.nu> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20051217081617.GK14690@granada.merseine.nu> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Muli Ben-Yehuda Cc: keir.fraser@cl.cam.ac.uk, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sat, 2005-12-17 at 10:16 +0200, Muli Ben-Yehuda wrote: > > Do you think it's worthwhile to try > > to achieve a high level inter-domain communication API which allows > > different split drivers to reuse the channel set-up, messaging, > > interrupt handling, flow-control and bulk data transfer code? > > Yes. But I'd like to see it developed and integrated piece by piece, > as a natural evolution of the existing code. If you churn the existing code by integrating a lot of incremental changes across all the drivers it may introduce significant instability and prevent other development from proceeding. An alternative approach would be to provide the infrastructure on the side and port the drivers to it one by one. That way the old and new versions of drivers could coexist in the tree which would allow other developers to use the old, stable set until the new ones were finished. Just a thought. -- Harry Butterworth