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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
