Am Montag, den 17.02.2014, 01:50 -0800 schrieb H. Peter Anvin: > 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. > Yes, but i think this is nearly impossible, because there must be modified a lot of headers and nobody can predict the side effects. - Stefani -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|