From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations. Date: Mon, 09 Jul 2007 14:41:04 -0500 Message-ID: <1184010064.26508.64.camel@basalt> References: Reply-To: Hollis Blanchard Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Jun Kamada , xen-devel@lists.xensource.com, xen-ppc-devel List-Id: xen-devel@lists.xenproject.org On Mon, 2007-07-09 at 20:26 +0100, Keir Fraser wrote: > On 9/7/07 20:20, "Hollis Blanchard" wrote: > > >> By the way, I wonder how PPC manages to build both drivers/char/mem.c and > >> drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be > >> that mem_fops defined by the Xen file is picked up by the generic file. If > >> !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen > >> mem_fops? > > > > Hmmm, yeah. Looks like we haven't tested that... :) > > If you don't need to build both then there is potentially no problem with > the Xen file hijacking the xlate_dev_mem() functions. PowerPC Linux builds support for multiple platforms, including multiple hypervisors, into a single binary (paravirt_ops was inspired by ppc_md). For the most part our Xen patches continue this model, but because we don't really test our Xen kernel on non-Xen platforms, there are a couple bugs that would need fixing. So compile-time ifdefs for /dev/mem won't work long-term, but I'm not really worried about it. -- Hollis Blanchard IBM Linux Technology Center