Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753147AbaBQJuc (ORCPT ); Mon, 17 Feb 2014 04:50:32 -0500 Received: from terminus.zytor.com ([198.137.202.10]:55620 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751341AbaBQJub (ORCPT ); Mon, 17 Feb 2014 04:50:31 -0500 Message-ID: <5301DB4B.2030103@zytor.com> Date: Mon, 17 Feb 2014 01:50:03 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefani Seibold CC: mingo@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, hpa@linux.intel.com, linux-tip-commits@vger.kernel.org, Andy Lutomirski Subject: Re: [tip:x86/vdso] x86, vdso: Instead of dummy functions, include < linux/spinlock_up.h> References: <1392587568-7325-10-git-send-email-stefani@seibold.net> <53018ABA.20005@zytor.com> <1392622944.1036.13.camel@wall-e.seibold.net> <5301D615.8090907@zytor.com> <1392630366.15660.6.camel@wall-e.seibold.net> In-Reply-To: <1392630366.15660.6.camel@wall-e.seibold.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/17/2014 01:46 AM, Stefani Seibold wrote: > Am Montag, den 17.02.2014, 01:27 -0800 schrieb H. Peter Anvin: >> On 02/16/2014 11:42 PM, Stefani Seibold wrote: >>> I think for the first time it will be okay to kick out the >>> _ASM_X86_SPINLOCK_H hack and accept the C=1 warnings. >>> >>> At next step it is necessary to make the whole BUILD_VDSO32 path in >>> vclock_gettime.c independent from the kernel headers, only uapi/ should >>> be included. >>> >>> The use of cycle_t must be replaced with u64. >>> >>> We need a own copy of __native_read_tsc(), __iter_div_u64_rem, smp_rmb() >>> and cpu_relax(). >> >> All of which are quite trivial. >> >>> For the non BUILD_VDSO32 path we must only move the #includes inside >>> this #ifndef BUILD_VDSO32 >> >> Sorry, didn't quite follow that. >> > > The solution is quite simple: In case of a 32 bit VDSO for a 64 bit > kernel fake a 32 bit kernel configuration. Than everything is fine and > all kernel headers will compile without warnings or errors, also make > C=1 will give no complains. > > The arch/x86/vdso/vdso32/vclock_gettime.c will now look like: > > #define BUILD_VDSO32 > > #ifdef CONFIG_X86_64 > > /* > * in case of a 32 bit VDSO for a 64 bit kernel fake a 32 bit kernel > * configuration > */ > #undef CONFIG_64BIT > #undef CONFIG_X86_64 > #undef CONFIG_ILLEGAL_POINTER_VALUE > > #define CONFIG_X86_32 1 > #define CONFIG_PAGE_OFFSET 0 > #define CONFIG_ILLEGAL_POINTER_VALUE 0 > > #define BUILD_VDSO32_64 > > #endif > > #include "../vclock_gettime.c" > > and the following modifications for arch/x86/include/asm/vgtod.h: > > #ifdef BUILD_VDSO32_64 > typedef u64 gtod_long_t; > #else > typedef unsigned long gtod_long_t; > #endif > > I tested it and i see no side effects. What do you think? > Clever. It is still a hack of course, and it would be better to getting to the point where we don't include random kernel headers but only uapi headers plus special headers sanitized specifically for the vdso, but the above looks like a good intermediate hack. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/