[LU-5327] powerpc64 defines __u64 differently for kernel- and user-space

Related — Thu, 14 Jun 2018 21:41:36 +0000

This is asm/types.h on powerpc64:

#ifndef _ASM_POWERPC_TYPES_H
#define _ASM_POWERPC_TYPES_H

/*
 * This is here because we used to use l64 for 64bit powerpc
 * and we don't want to impact user mode with our change to ll64
 * in the kernel.
 */
#if defined(__powerpc64__) && !defined(__KERNEL__)
# include <asm-generic/int-l64.h>
#else
# include <asm-generic/int-ll64.h>
#endif

#ifndef __ASSEMBLY__

/*
 * This file is never included by application software unless
 * explicitly requested (e.g., via linux/types.h) in which case the
 * application is Linux specific so (user-) name space pollution is
 * not a major issue.  However, for interoperability, libraries still
 * need to be careful to avoid a name clashes.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version
 * 2 of the License, or (at your option) any later version.
 */

#ifdef __powerpc64__
typedef unsigned int umode_t;
#else
typedef unsigned short umode_t;
#endif

typedef struct {
        __u32 u[4];
} __attribute__((aligned(16))) __vector128;

#endif /* __ASSEMBLY__ */

This breaks the use of HAVE_KERN__U64_LONG_LONG to define the LP*64 macros. This causes compile errors in lustre/utils on powerpc64.

Whamcloud Community JIRA

[LU-5327] powerpc64 defines __u64 differently for kernel- and user-space