On Sun, Apr 22, 2018 at 2:38 PM, H.J. Lu <hjl.tools@xxxxxxxxx> wrote: > On Fri, Apr 20, 2018 at 7:38 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> On Fri, Apr 20, 2018 at 3:53 PM, Jeffrey Walton <noloader@xxxxxxxxx> wrote: > > Glibc has correct header files for system calls. I have a very old > program to check if Linux kernel header files are correct for user > space: > > https://github.com/hjl-tools/linux-header > > It needs update to check uapi. Simply running 'make' on a regular distro shows this output: --- kernel.x32.out 2018-04-22 22:10:16.053432423 +0200 +++ glibc.x32.out 2018-04-22 22:10:16.073432838 +0200 @@ -10,9 +10,9 @@ size of daddr_t: 4 size of __ipc_pid_t: 4 size of struct ipc_perm: 48 size of mqd_t: 4 -size of struct msqid_ds: 144 +size of struct msqid_ds: 120 size of struct semid_ds: 104 -size of struct shmid_ds: 136 +size of struct shmid_ds: 112 size of struct shminfo: 72 size of struct timeval: 16 size of struct timespec: 16 @@ -22,8 +22,8 @@ size of struct mq_attr: 64 size of struct rlimit: 16 size of struct rusage: 144 size of struct stat: 144 -size of struct statfs: 64 -size of struct statfs64: 88 +size of struct statfs: 120 +size of struct statfs64: 120 size of struct timex: 208 size of struct msginfo: 32 size of struct msgbuf: 16 This seems plausible, the statfs structure clearly has the same problem as msqid_ds/shmid_ds based on its usage of '__statfs_word' which is now defined as '__u32' rather than '__kernel_long_t'. It should be trivial to override __statfs_word from arch/x86/include/uapi/asm/statfs.h I've checked the other uses of __BITS_PER_LONG in the uapi headers now, and all the others are either not relevant for x32 (either definition is fine) or it has to be __BITS_PER_LONG=32. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
