From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [RFC PATCH v2 06/22] xen/arm: its: Port ITS driver to xen Date: Thu, 2 Apr 2015 10:25:32 +0100 Message-ID: <1427966732.4037.24.camel@citrix.com> References: <1426775889-29442-1-git-send-email-vijay.kilari@gmail.com> <1426775889-29442-7-git-send-email-vijay.kilari@gmail.com> <1427888093.2115.274.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari Cc: Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , Julien Grall , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org On Thu, 2015-04-02 at 13:55 +0530, Vijay Kilari wrote: > On Wed, Apr 1, 2015 at 5:04 PM, Ian Campbell wrote: > > On Thu, 2015-03-19 at 20:07 +0530, vijay.kilari@gmail.com wrote: > >> From: Vijaya Kumar K > >> > >> This patch just makes ITS driver taken from linux > >> compiles in xen environment. > > > > What is your intention wrt future updates to this driver? > > > > Are you intending to keep things in sync and import things from the > > Linux side (similar to the smmu drviers) or are you taking the Linux > > code as a starting point and intending that it then be maintained > > independently as a Xen driver from then on? > > Yes, I intend to keep things in sync with Linux driver. > I have kept most the code same as Linux side except removing unused code. There is a tonne of changes going on if that is your goal, in particular in this patch but also in some of the following refactoring patches. When this series is over it seems like the driver would bear very little resemblance to the Linux one. If you want to go this route then to aid in future synchronisation from Linux patches the goal should be to make the changes to the Linux code as minimal as possible, by defining shim functions and typedefs etc at the top of the file, e.g. as Julien has tried to do with the smmu driver. Unlike the smmu stuff, which has a reasonably small and well-defined interface to the kernel which can be easily shimmed between Xen and Linux it's not clear to me that this approach is workable for ITS, the Xen and Linux interrupt handling systems are rather different and ITS needs to be more tightly integrated with other bits of Xen, in particular the GIC drivers. However if you think maintaining something which can be synchronised from Linux is viable and desirable then that's ok by me. Ian.