From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] fix build when CONFIG_COMPAT disabled Date: Thu, 11 Jan 2007 17:57:45 +0000 Message-ID: References: <45A67470.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45A67470.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , xen-devel@lists.xensource.com, Keir Fraser Cc: John Levon List-Id: xen-devel@lists.xenproject.org On 11/1/07 16:31, "Jan Beulich" wrote: >> Should we bother to #ifdef where we don't need to? It's ugly and the >> compiler should be able to remove dead code where a condition evaluates to >> zero at compile time: we already have IS_COMPAT(d) hardcoded to zero if >> !CONFIG_COMPAT, which is enough to give the compiler a fair chance. > > Generally no, but in the one case in the patch we have to, as the structure > member (mm_arg_xlat_l3) doesn't exist without CONFIG_COMPAT. CONFIG_COMPAT isn't a real config option though. It's a function of the architecture we're building for. So we don't need ifdef CONFIG_COMPAT in any x86/64-specific code. I'm very keen to get rid of CONFIG_* where possible. In x86 code we can variously remove ifdefs or turn them into CONFIG_X86_64. We probably need to keep CONFIG_COMPAT in some common code I guess. This really follows my view that much of this new code should simply be viewed as an always-on x86/64 extension, and that code should be propagated down into arch/x86 and arch/x86/x86_64 as much as possible to reflect that. -- Keir