* limits.h in tools/ @ 2024-04-23 18:58 Andy Shevchenko 2024-04-23 19:22 ` Arnaldo Carvalho de Melo 0 siblings, 1 reply; 10+ messages in thread From: Andy Shevchenko @ 2024-04-23 18:58 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, linux-kernel, Willy Tarreau, Thomas Weißschuh Cc: Andrew Morton, willy, Namhyung Kim It seems tons of the code in tools include linux/limits.h. But I haven't found where do we copy it. Any pointers? Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-23 18:58 limits.h in tools/ Andy Shevchenko @ 2024-04-23 19:22 ` Arnaldo Carvalho de Melo 2024-04-23 19:29 ` Andy Shevchenko 0 siblings, 1 reply; 10+ messages in thread From: Arnaldo Carvalho de Melo @ 2024-04-23 19:22 UTC (permalink / raw) To: Andy Shevchenko Cc: linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > It seems tons of the code in tools include linux/limits.h. But I haven't found > where do we copy it. Any pointers? > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. ⬢[acme@toolbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h --- /usr/include/linux/limits.h 2024-01-31 21:00:00.000000000 -0300 +++ include/uapi/linux/limits.h 2024-02-03 16:18:02.652000641 -0300 @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ -#ifndef _LINUX_LIMITS_H -#define _LINUX_LIMITS_H +#ifndef _UAPI_LINUX_LIMITS_H +#define _UAPI_LINUX_LIMITS_H #define NR_OPEN 1024 ⬢[acme@toolbox perf-tools-next]$ And in the places where I test build perf I saw no problem so far, the build failures below are unrelated, but still outstanding, see below. But then is for building tools/, not the kernel, right? The discussion you said this question was based on is about changing include/linux/xarray.h, a kernel file, so should really be including just kernel headers, files in the kernel source tree, outside tools/, I don't see where what tools/ uses to build is relevant here? Can you please elaborate? - Arnaldo 1 113.99 almalinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20) , clang version 16.0.6 (Red Hat 16.0.6-2.module_el8.9.0+3621+df7f7146) flex 2.6.1 2 90.56 almalinux:9 : Ok gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2) , clang version 16.0.6 (Red Hat 16.0.6-1.el9) flex 2.6.4 3 96.32 alpine:3.15 : Ok gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027 , Alpine clang version 12.0.1 flex 2.6.4 4 95.11 alpine:3.16 : Ok gcc (Alpine 11.2.1_git20220219) 11.2.1 20220219 , Alpine clang version 13.0.1 flex 2.6.4 5 80.81 alpine:3.17 : Ok gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924 , Alpine clang version 15.0.7 flex 2.6.4 6 75.39 alpine:3.18 : Ok gcc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924 , Alpine clang version 16.0.6 flex 2.6.4 7 85.18 alpine:3.19 : Ok gcc (Alpine 13.2.1_git20231014) 13.2.1 20231014 , Alpine clang version 17.0.5 flex 2.6.4 8 86.89 alpine:edge : Ok gcc (Alpine 13.2.1_git20240309) 13.2.1 20240309 , Alpine clang version 17.0.6 flex 2.6.4 9 60.25 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-17) , clang version 11.1.0 (Amazon Linux 2 11.1.0-1.amzn2.0.2) flex 2.5.37 10 78.11 amazonlinux:2023 : Ok gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2) , clang version 15.0.7 (Amazon Linux 15.0.7-3.amzn2023.0.1) flex 2.6.4 11 77.00 amazonlinux:devel : Ok gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4) , clang version 15.0.6 (Amazon Linux 15.0.6-3.amzn2023.0.2) flex 2.6.4 12 96.53 archlinux:base : Ok gcc (GCC) 13.2.1 20230801 , clang version 17.0.6 flex 2.6.4 13 80.73 centos:stream : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-21) , clang version 17.0.6 (Red Hat 17.0.6-1.module_el8+767+9fa966b8) flex 2.6.1 14 76.60 clearlinux:latest : Ok gcc (Clear Linux OS for Intel Architecture) 13.2.1 20240402 releases/gcc-13.2.0-946-g11f37868bb , clang version 17.0.6 flex 2.6.4 15 52.34 debian:10 : Ok gcc (Debian 8.3.0-6) 8.3.0 , Debian clang version 11.0.1-2~deb10u1 flex 2.6.4 16 69.91 debian:11 : Ok gcc (Debian 10.2.1-6) 10.2.1 20210110 , Debian clang version 13.0.1-6~deb11u1 flex 2.6.4 17 69.93 debian:12 : Ok gcc (Debian 12.2.0-14) 12.2.0 , Debian clang version 14.0.6 flex 2.6.4 18 73.52 debian:experimental : Ok gcc (Debian 13.2.0-23) 13.2.0 , Debian clang version 16.0.6 (24) flex 2.6.4 19 4.22 debian:experimental-x-arm64 : FAIL gcc version 13.2.0 (Debian 13.2.0-12) from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:2:10: fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such file or directory 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. CC /tmp/build/perf/libbpf/staticobjs/zip.o CC /tmp/build/perf/libbpf/staticobjs/elf.o CC /tmp/build/perf/libbpf/staticobjs/features.o LD /tmp/build/perf/libapi/fs/libapi-in.o In file included from /git/perf-6.9.0-rc5/tools/include/uapi/linux/bpf_perf_event.h:11, from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:2:10: fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such file or directory 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[4]: *** [/git/perf-6.9.0-rc5/tools/build/Makefile.build:105: /tmp/build/perf/libbpf/staticobjs/libbpf.o] Error 1 make[4]: *** Waiting for unfinished jobs.... LD /tmp/build/perf/libapi/libapi-in.o AR /tmp/build/perf/libapi/libapi.a LD /tmp/build/perf/libperf/libperf-in.o 20 13.87 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 12.3.0-6) 12.3.0 flex 2.6.4 21 14.02 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 12.3.0-6) 12.3.0 flex 2.6.4 22 14.20 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 12.3.0-6) 12.3.0 flex 2.6.4 23 81.08 fedora:35 : Ok gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-3) , clang version 13.0.1 (Fedora 13.0.1-1.fc35) flex 2.6.4 24 80.55 fedora:36 : Ok gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4) , clang version 14.0.5 (Fedora 14.0.5-2.fc36) flex 2.6.4 25 78.80 fedora:37 : Ok gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1) , clang version 15.0.7 (Fedora 15.0.7-2.fc37) flex 2.6.4 26 72.57 fedora:38 : Ok gcc (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4) , clang version 16.0.6 (Fedora 16.0.6-4.fc38) flex 2.6.4 27 67.84 fedora:39 : Ok gcc (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7) , clang version 17.0.6 (Fedora 17.0.6-2.fc39) flex 2.6.4 28 76.14 fedora:40 : Ok gcc (GCC) 14.0.1 20240411 (Red Hat 14.0.1-0) , clang version 18.1.1 (Fedora 18.1.1-1.fc40) flex 2.6.4 29 72.49 fedora:rawhide : Ok gcc (GCC) 14.0.1 20240411 (Red Hat 14.0.1-0) , clang version 18.1.3 (Fedora 18.1.3-2.fc41) flex 2.6.4 30 27.98 gentoo:stage3 : Ok gcc (Gentoo 13.2.1_p20240210 p14) 13.2.1 20240210 flex 2.6.4 31 83.73 manjaro:base : Ok gcc (GCC) 13.2.1 20230801 , clang version 16.0.6 flex 2.6.4 32 94.35 opensuse:15.4 : Ok gcc (SUSE Linux) 7.5.0 , clang version 15.0.7 flex 2.6.4 33 97.90 opensuse:15.5 : Ok gcc (SUSE Linux) 7.5.0 , clang version 15.0.7 flex 2.6.4 34 93.92 opensuse:tumbleweed : Ok gcc (SUSE Linux) 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d829b70f23] , clang version 17.0.6 flex 2.6.4 35 81.04 oraclelinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20.0.3) , clang version 16.0.6 (Red Hat 16.0.6-2.0.1.module+el8.9.0+90129+d3ee8717) flex 2.6.1 36 78.68 oraclelinux:9 : Ok gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2.1.0.1) , clang version 16.0.6 (Red Hat 16.0.6-1.0.1.el9) flex 2.6.4 37 83.49 rockylinux:8 : Ok gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20) , clang version 16.0.6 (Red Hat 16.0.6-2.module+el8.9.0+1651+e10a8f6d) flex 2.6.1 38 80.23 rockylinux:9 : Ok gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2) , clang version 16.0.6 (Red Hat 16.0.6-1.el9) flex 2.6.4 39 23.87 ubuntu:18.04 : Ok gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 flex 2.6.4 40 15.99 ubuntu:18.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 flex 2.6.4 41 3.33 ubuntu:18.04-x-arm64 : FAIL gcc version 7.5.0 (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:2:10: fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such file or directory #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. LD /tmp/build/perf/libapi/libapi-in.o AR /tmp/build/perf/libapi/libapi.a LD /tmp/build/perf/libperf/libperf-in.o AR /tmp/build/perf/libperf/libperf.a In file included from /git/perf-6.9.0-rc5/tools/include/uapi/linux/bpf_perf_event.h:11:0, from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:2:10: fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such file or directory #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. /git/perf-6.9.0-rc5/tools/build/Makefile.build:105: recipe for target '/tmp/build/perf/libbpf/staticobjs/libbpf.o' failed make[4]: *** [/tmp/build/perf/libbpf/staticobjs/libbpf.o] Error 1 make[4]: *** Waiting for unfinished jobs.... LD /tmp/build/perf/libsubcmd/libsubcmd-in.o AR /tmp/build/perf/libsubcmd/libsubcmd.a 42 15.36 ubuntu:18.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 flex 2.6.4 43 15.91 ubuntu:18.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 flex 2.6.4 44 15.80 ubuntu:18.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 flex 2.6.4 45 3.36 ubuntu:18.04-x-riscv64 : FAIL gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:8:10: fatal error: ../../arch/riscv/include/uapi/asm/bpf_perf_event.h: No such file or directory #include "../../arch/riscv/include/uapi/asm/bpf_perf_event.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. CC /tmp/build/perf/libbpf/staticobjs/zip.o CC /tmp/build/perf/libbpf/staticobjs/elf.o AR /tmp/build/perf/libperf/libperf.a CC /tmp/build/perf/libbpf/staticobjs/features.o In file included from /git/perf-6.9.0-rc5/tools/include/uapi/linux/bpf_perf_event.h:11:0, from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:8:10: fatal error: ../../arch/riscv/include/uapi/asm/bpf_perf_event.h: No such file or directory #include "../../arch/riscv/include/uapi/asm/bpf_perf_event.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. /git/perf-6.9.0-rc5/tools/build/Makefile.build:105: recipe for target '/tmp/build/perf/libbpf/staticobjs/libbpf.o' failed make[4]: *** [/tmp/build/perf/libbpf/staticobjs/libbpf.o] Error 1 make[4]: *** Waiting for unfinished jobs.... LD /tmp/build/perf/libsubcmd/libsubcmd-in.o AR /tmp/build/perf/libsubcmd/libsubcmd.a 46 3.53 ubuntu:18.04-x-s390 : FAIL gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:6:10: fatal error: ../../arch/s390/include/uapi/asm/bpf_perf_event.h: No such file or directory #include "../../arch/s390/include/uapi/asm/bpf_perf_event.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. LD /tmp/build/perf/libapi/libapi-in.o AR /tmp/build/perf/libapi/libapi.a LD /tmp/build/perf/libperf/libperf-in.o AR /tmp/build/perf/libperf/libperf.a In file included from /git/perf-6.9.0-rc5/tools/include/uapi/linux/bpf_perf_event.h:11:0, from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:6:10: fatal error: ../../arch/s390/include/uapi/asm/bpf_perf_event.h: No such file or directory #include "../../arch/s390/include/uapi/asm/bpf_perf_event.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. /git/perf-6.9.0-rc5/tools/build/Makefile.build:105: recipe for target '/tmp/build/perf/libbpf/staticobjs/libbpf.o' failed make[4]: *** [/tmp/build/perf/libbpf/staticobjs/libbpf.o] Error 1 make[4]: *** Waiting for unfinished jobs.... LD /tmp/build/perf/libsubcmd/libsubcmd-in.o AR /tmp/build/perf/libsubcmd/libsubcmd.a 47 15.73 ubuntu:18.04-x-sh4 : Ok sh4-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 flex 2.6.4 48 14.17 ubuntu:18.04-x-sparc64 : Ok sparc64-linux-gnu-gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 flex 2.6.4 49 23.06 ubuntu:20.04 : Ok gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0 flex 2.6.4 50 16.36 ubuntu:20.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 10.5.0-1ubuntu1~20.04) 10.5.0 flex 2.6.4 51 127.69 ubuntu:22.04 : Ok gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 , Ubuntu clang version 14.0.0-1ubuntu1.1 flex 2.6.4 52 2.87 ubuntu:22.04-x-riscv64 : FAIL gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:8:10: fatal error: ../../arch/riscv/include/uapi/asm/bpf_perf_event.h: No such file or directory 8 | #include "../../arch/riscv/include/uapi/asm/bpf_perf_event.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. CC /tmp/build/perf/libbpf/staticobjs/features.o LD /tmp/build/perf/libapi/fs/libapi-in.o LD /tmp/build/perf/libapi/libapi-in.o AR /tmp/build/perf/libapi/libapi.a In file included from /git/perf-6.9.0-rc5/tools/include/uapi/linux/bpf_perf_event.h:11, from libbpf.c:36: /git/perf-6.9.0-rc5/tools/include/uapi/asm/bpf_perf_event.h:8:10: fatal error: ../../arch/riscv/include/uapi/asm/bpf_perf_event.h: No such file or directory 8 | #include "../../arch/riscv/include/uapi/asm/bpf_perf_event.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[4]: *** [/git/perf-6.9.0-rc5/tools/build/Makefile.build:105: /tmp/build/perf/libbpf/staticobjs/libbpf.o] Error 1 make[4]: *** Waiting for unfinished jobs.... LD /tmp/build/perf/libsubcmd/libsubcmd-in.o AR /tmp/build/perf/libsubcmd/libsubcmd.a make[3]: *** [Makefile:157: /tmp/build/perf/libbpf/staticobjs/libbpf-in.o] Error 2 53 88.66 ubuntu:23.04 : Ok gcc (Ubuntu 12.3.0-1ubuntu1~23.04) 12.3.0 , Ubuntu clang version 15.0.7 flex 2.6.4 54 75.72 ubuntu:23.10 : Ok gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0 , Ubuntu clang version 16.0.6 (15) flex 2.6.4 55 78.64 ubuntu:24.04 : Ok gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0 , Ubuntu clang version 18.1.2 (1ubuntu3) flex 2.6.4 BUILD_TARBALL_HEAD=3b8a6dcedaec6def48b3d597f3a8437938c3eaa4 56 3296.82 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-23 19:22 ` Arnaldo Carvalho de Melo @ 2024-04-23 19:29 ` Andy Shevchenko 2024-04-23 19:30 ` Andy Shevchenko 2024-04-23 20:07 ` Arnaldo Carvalho de Melo 0 siblings, 2 replies; 10+ messages in thread From: Andy Shevchenko @ 2024-04-23 19:29 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > where do we copy it. Any pointers? > > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. > > ⬢[acme@toolbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h > --- /usr/include/linux/limits.h 2024-01-31 21:00:00.000000000 -0300 > +++ include/uapi/linux/limits.h 2024-02-03 16:18:02.652000641 -0300 > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > -#ifndef _LINUX_LIMITS_H > -#define _LINUX_LIMITS_H > +#ifndef _UAPI_LINUX_LIMITS_H > +#define _UAPI_LINUX_LIMITS_H > > #define NR_OPEN 1024 > > ⬢[acme@toolbox perf-tools-next]$ > > And in the places where I test build perf I saw no problem so far, the > build failures below are unrelated, but still outstanding, see below. > > But then is for building tools/, not the kernel, right? The discussion > you said this question was based on is about changing > include/linux/xarray.h, a kernel file, so should really be including > just kernel headers, files in the kernel source tree, outside tools/, I > don't see where what tools/ uses to build is relevant here? Can you > please elaborate? I believe the tool in question is tools/testing/radix-tree/xarray.c. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-23 19:29 ` Andy Shevchenko @ 2024-04-23 19:30 ` Andy Shevchenko 2024-04-24 13:46 ` Liam R. Howlett 2024-04-23 20:07 ` Arnaldo Carvalho de Melo 1 sibling, 1 reply; 10+ messages in thread From: Andy Shevchenko @ 2024-04-23 19:30 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, Liam R. Howlett Cc: linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim +Cc: Liam, the maintainer of the tool in question. On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote: > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > > where do we copy it. Any pointers? > > > > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. > > > > ⬢[acme@toolbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h > > --- /usr/include/linux/limits.h 2024-01-31 21:00:00.000000000 -0300 > > +++ include/uapi/linux/limits.h 2024-02-03 16:18:02.652000641 -0300 > > @@ -1,6 +1,6 @@ > > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > -#ifndef _LINUX_LIMITS_H > > -#define _LINUX_LIMITS_H > > +#ifndef _UAPI_LINUX_LIMITS_H > > +#define _UAPI_LINUX_LIMITS_H > > > > #define NR_OPEN 1024 > > > > ⬢[acme@toolbox perf-tools-next]$ > > > > And in the places where I test build perf I saw no problem so far, the > > build failures below are unrelated, but still outstanding, see below. > > > > But then is for building tools/, not the kernel, right? The discussion > > you said this question was based on is about changing > > include/linux/xarray.h, a kernel file, so should really be including > > just kernel headers, files in the kernel source tree, outside tools/, I > > don't see where what tools/ uses to build is relevant here? Can you > > please elaborate? > > I believe the tool in question is tools/testing/radix-tree/xarray.c. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-23 19:30 ` Andy Shevchenko @ 2024-04-24 13:46 ` Liam R. Howlett 2024-04-24 14:19 ` Andy Shevchenko 2024-04-24 14:19 ` Arnaldo Carvalho de Melo 0 siblings, 2 replies; 10+ messages in thread From: Liam R. Howlett @ 2024-04-24 13:46 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnaldo Carvalho de Melo, linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim * Andy Shevchenko <andriy.shevchenko@intel.com> [240423 15:31]: > +Cc: Liam, the maintainer of the tool in question. I maintain the maple.c file in that directory, not the xarray.c one. xarray is willy, and I depend on some of the functions from the xarray. > > On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote: > > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > > > where do we copy it. Any pointers? > > > > > > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. I was unable to locate this discussion. > > > > > > ⬢[acme@toolbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h > > > --- /usr/include/linux/limits.h 2024-01-31 21:00:00.000000000 -0300 > > > +++ include/uapi/linux/limits.h 2024-02-03 16:18:02.652000641 -0300 > > > @@ -1,6 +1,6 @@ > > > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > > -#ifndef _LINUX_LIMITS_H > > > -#define _LINUX_LIMITS_H > > > +#ifndef _UAPI_LINUX_LIMITS_H > > > +#define _UAPI_LINUX_LIMITS_H > > > > > > #define NR_OPEN 1024 > > > > > > ⬢[acme@toolbox perf-tools-next]$ > > > > > > And in the places where I test build perf I saw no problem so far, the > > > build failures below are unrelated, but still outstanding, see below. > > > > > > But then is for building tools/, not the kernel, right? The discussion > > > you said this question was based on is about changing > > > include/linux/xarray.h, a kernel file, so should really be including > > > just kernel headers, files in the kernel source tree, outside tools/, I > > > don't see where what tools/ uses to build is relevant here? Can you > > > please elaborate? > > > > I believe the tool in question is tools/testing/radix-tree/xarray.c. I'm not sure what is being asked. Are you suggesting that the linux kernel xarray.h header is including non-kernel headers? I don't believe this to be true. However, the xarray.h tools/testing/radix-tree header certainly pulls in the kernel version of its header. The point here is that we want to test the xarray, so we need to have access to the API, but including it after setting things up so it will work without the kernel. The directory you are point to is a testing directory which uses a combination of kernel headers and custom headers (to avoid pulling in the entire kernel) to build a test application. Sometimes the real headers are used, but other times we are required to write a small function to do what is expected (eg: allocating kmem_cache objects). So our tools may include some kernel headers directly, for testing those functions. It also includes testing headers where we just need the defined functionality provided for the testing framework. Specific to limits.h, if you look in the kernel header, you will see: #include <uapi/linux/limits.h> So, most likely, just including the uapi header satisfied the requirement without pulling in more headers with, potentially, other issues. IIRC including the types.h header (also in the kernel limits.h) caused issues for me in the past. I hope this helps answer your questions. Thanks, Liam ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-24 13:46 ` Liam R. Howlett @ 2024-04-24 14:19 ` Andy Shevchenko 2024-04-24 14:40 ` Liam R. Howlett 2024-04-24 14:19 ` Arnaldo Carvalho de Melo 1 sibling, 1 reply; 10+ messages in thread From: Andy Shevchenko @ 2024-04-24 14:19 UTC (permalink / raw) To: Liam R. Howlett Cc: Arnaldo Carvalho de Melo, linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim On Wed, Apr 24, 2024 at 09:46:46AM -0400, Liam R. Howlett wrote: > * Andy Shevchenko <andriy.shevchenko@intel.com> [240423 15:31]: > > +Cc: Liam, the maintainer of the tool in question. > > I maintain the maple.c file in that directory, not the xarray.c one. > xarray is willy, and I depend on some of the functions from the xarray. Ah, okay, good to know. > > On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote: > > > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > > > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > > > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > > > > where do we copy it. Any pointers? > > > > > > > > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. > > I was unable to locate this discussion. `b4 mbox 20220603183231.15159C385A9@smtp.kernel.org` works for me $ b4 mbox 20220603183231.15159C385A9@smtp.kernel.org Grabbing thread from lore.kernel.org/all/20220603183231.15159C385A9@smtp.kernel.org/t.mbox.gz 8 messages in the thread Saved ./20220603183231.15159C385A9@smtp.kernel.org.mbx > > > > ⬢[acme@toolbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h > > > > --- /usr/include/linux/limits.h 2024-01-31 21:00:00.000000000 -0300 > > > > +++ include/uapi/linux/limits.h 2024-02-03 16:18:02.652000641 -0300 > > > > @@ -1,6 +1,6 @@ > > > > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > > > -#ifndef _LINUX_LIMITS_H > > > > -#define _LINUX_LIMITS_H > > > > +#ifndef _UAPI_LINUX_LIMITS_H > > > > +#define _UAPI_LINUX_LIMITS_H > > > > > > > > #define NR_OPEN 1024 > > > > > > > > ⬢[acme@toolbox perf-tools-next]$ > > > > > > > > And in the places where I test build perf I saw no problem so far, the > > > > build failures below are unrelated, but still outstanding, see below. > > > > > > > > But then is for building tools/, not the kernel, right? The discussion > > > > you said this question was based on is about changing > > > > include/linux/xarray.h, a kernel file, so should really be including > > > > just kernel headers, files in the kernel source tree, outside tools/, I > > > > don't see where what tools/ uses to build is relevant here? Can you > > > > please elaborate? > > > > > > I believe the tool in question is tools/testing/radix-tree/xarray.c. > > I'm not sure what is being asked. Are you suggesting that the linux > kernel xarray.h header is including non-kernel headers? I don't believe > this to be true. No. The problem here that tooling relies basically on the external limits.h. I.o.w. from the current user space. > However, the xarray.h tools/testing/radix-tree header certainly pulls in > the kernel version of its header. The point here is that we want to > test the xarray, so we need to have access to the API, but including it > after setting things up so it will work without the kernel. > > The directory you are point to is a testing directory which uses a > combination of kernel headers and custom headers (to avoid pulling in > the entire kernel) to build a test application. Sometimes the real > headers are used, but other times we are required to write a small > function to do what is expected (eg: allocating kmem_cache objects). > > So our tools may include some kernel headers directly, for testing those > functions. It also includes testing headers where we just need the > defined functionality provided for the testing framework. > > Specific to limits.h, if you look in the kernel header, you will see: > > #include <uapi/linux/limits.h> > > So, most likely, just including the uapi header satisfied the > requirement without pulling in more headers with, potentially, other > issues. IIRC including the types.h header (also in the kernel limits.h) > caused issues for me in the past. > > I hope this helps answer your questions. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-24 14:19 ` Andy Shevchenko @ 2024-04-24 14:40 ` Liam R. Howlett 2024-04-24 14:46 ` Liam R. Howlett 0 siblings, 1 reply; 10+ messages in thread From: Liam R. Howlett @ 2024-04-24 14:40 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnaldo Carvalho de Melo, linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim * Andy Shevchenko <andriy.shevchenko@intel.com> [240424 10:19]: ... > > > On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote: > > > > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > > > > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > > > > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > > > > > where do we copy it. Any pointers? > > > > > > > > > > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. > > > > I was unable to locate this discussion. > > `b4 mbox 20220603183231.15159C385A9@smtp.kernel.org` > > works for me > > $ b4 mbox 20220603183231.15159C385A9@smtp.kernel.org > Grabbing thread from lore.kernel.org/all/20220603183231.15159C385A9@smtp.kernel.org/t.mbox.gz > 8 messages in the thread > Saved ./20220603183231.15159C385A9@smtp.kernel.org.mbx Interesting, I usually use the web search for the id and that failed me in this case. I use b4 for patch fetching and reviewing. > > > > > > ⬢[acme@toolbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h > > > > > --- /usr/include/linux/limits.h 2024-01-31 21:00:00.000000000 -0300 > > > > > +++ include/uapi/linux/limits.h 2024-02-03 16:18:02.652000641 -0300 > > > > > @@ -1,6 +1,6 @@ > > > > > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > > > > -#ifndef _LINUX_LIMITS_H > > > > > -#define _LINUX_LIMITS_H > > > > > +#ifndef _UAPI_LINUX_LIMITS_H > > > > > +#define _UAPI_LINUX_LIMITS_H > > > > > > > > > > #define NR_OPEN 1024 > > > > > > > > > > ⬢[acme@toolbox perf-tools-next]$ > > > > > > > > > > And in the places where I test build perf I saw no problem so far, the > > > > > build failures below are unrelated, but still outstanding, see below. > > > > > > > > > > But then is for building tools/, not the kernel, right? The discussion > > > > > you said this question was based on is about changing > > > > > include/linux/xarray.h, a kernel file, so should really be including > > > > > just kernel headers, files in the kernel source tree, outside tools/, I > > > > > don't see where what tools/ uses to build is relevant here? Can you > > > > > please elaborate? > > > > > > > > I believe the tool in question is tools/testing/radix-tree/xarray.c. > > > > I'm not sure what is being asked. Are you suggesting that the linux > > kernel xarray.h header is including non-kernel headers? I don't believe > > this to be true. > > No. The problem here that tooling relies basically on the external limits.h. > I.o.w. from the current user space. Indeed this is the case. I verified with an ifndef, error in main.c and we seem to be using the non-uapi version. maple.c also depends on external libraries (userspace rcu) being installed, so I'm not entirely sure how isolated we need the testing to be as they are not shipped or built besides by developers (and bots) to test the functionality in userspace. As for limits.h, we can probably migrate to the uapi version but I don't really see a reason. Thanks, Liam ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-24 14:40 ` Liam R. Howlett @ 2024-04-24 14:46 ` Liam R. Howlett 0 siblings, 0 replies; 10+ messages in thread From: Liam R. Howlett @ 2024-04-24 14:46 UTC (permalink / raw) To: Andy Shevchenko Cc: Arnaldo Carvalho de Melo, linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim * Liam R. Howlett <Liam.Howlett@oracle.com> [240424 10:40]: > * Andy Shevchenko <andriy.shevchenko@intel.com> [240424 10:19]: > ... > > > > > On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote: > > > > > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > > > > > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > > > > > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > > > > > > where do we copy it. Any pointers? > > > > > > > > > > > > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. > > > > > > I was unable to locate this discussion. > > > > `b4 mbox 20220603183231.15159C385A9@smtp.kernel.org` > > > > works for me > > > > $ b4 mbox 20220603183231.15159C385A9@smtp.kernel.org > > Grabbing thread from lore.kernel.org/all/20220603183231.15159C385A9@smtp.kernel.org/t.mbox.gz > > 8 messages in the thread > > Saved ./20220603183231.15159C385A9@smtp.kernel.org.mbx > > Interesting, I usually use the web search for the id and that failed me > in this case. I use b4 for patch fetching and reviewing. Okay, I see what this is about. Thanks. We should probably switch to using the right header in all locations in our testing directory. Thanks, Liam ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-24 13:46 ` Liam R. Howlett 2024-04-24 14:19 ` Andy Shevchenko @ 2024-04-24 14:19 ` Arnaldo Carvalho de Melo 1 sibling, 0 replies; 10+ messages in thread From: Arnaldo Carvalho de Melo @ 2024-04-24 14:19 UTC (permalink / raw) To: Liam R. Howlett Cc: Andy Shevchenko, linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim On Wed, Apr 24, 2024 at 09:46:46AM -0400, Liam R. Howlett wrote: > * Andy Shevchenko <andriy.shevchenko@intel.com> [240423 15:31]: > > +Cc: Liam, the maintainer of the tool in question. > > I maintain the maple.c file in that directory, not the xarray.c one. > xarray is willy, and I depend on some of the functions from the xarray. > > > > > On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote: > > > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > > > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > > > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > > > > where do we copy it. Any pointers? > > > > > > > > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. > > I was unable to locate this discussion. I managed to do it by using: https://lkml.kernel.org/r/ + that Message-ID, i.e.: https://lkml.kernel.org/r/20220603183231.15159C385A9@smtp.kernel.org. > > > > > > > > ⬢[acme@toolbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h > > > > --- /usr/include/linux/limits.h 2024-01-31 21:00:00.000000000 -0300 > > > > +++ include/uapi/linux/limits.h 2024-02-03 16:18:02.652000641 -0300 > > > > @@ -1,6 +1,6 @@ > > > > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > > > -#ifndef _LINUX_LIMITS_H > > > > -#define _LINUX_LIMITS_H > > > > +#ifndef _UAPI_LINUX_LIMITS_H > > > > +#define _UAPI_LINUX_LIMITS_H > > > > > > > > #define NR_OPEN 1024 > > > > > > > > ⬢[acme@toolbox perf-tools-next]$ > > > > > > > > And in the places where I test build perf I saw no problem so far, the > > > > build failures below are unrelated, but still outstanding, see below. > > > > > > > > But then is for building tools/, not the kernel, right? The discussion > > > > you said this question was based on is about changing > > > > include/linux/xarray.h, a kernel file, so should really be including > > > > just kernel headers, files in the kernel source tree, outside tools/, I > > > > don't see where what tools/ uses to build is relevant here? Can you > > > > please elaborate? > > > > > > I believe the tool in question is tools/testing/radix-tree/xarray.c. > > I'm not sure what is being asked. Are you suggesting that the linux > kernel xarray.h header is including non-kernel headers? I don't believe > this to be true. > > However, the xarray.h tools/testing/radix-tree header certainly pulls in > the kernel version of its header. The point here is that we want to > test the xarray, so we need to have access to the API, but including it > after setting things up so it will work without the kernel. > > The directory you are point to is a testing directory which uses a > combination of kernel headers and custom headers (to avoid pulling in > the entire kernel) to build a test application. Sometimes the real > headers are used, but other times we are required to write a small > function to do what is expected (eg: allocating kmem_cache objects). > > So our tools may include some kernel headers directly, for testing those > functions. It also includes testing headers where we just need the > defined functionality provided for the testing framework. > > Specific to limits.h, if you look in the kernel header, you will see: > > #include <uapi/linux/limits.h> > > So, most likely, just including the uapi header satisfied the > requirement without pulling in more headers with, potentially, other > issues. IIRC including the types.h header (also in the kernel limits.h) > caused issues for me in the past. > > I hope this helps answer your questions. > > Thanks, > Liam ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: limits.h in tools/ 2024-04-23 19:29 ` Andy Shevchenko 2024-04-23 19:30 ` Andy Shevchenko @ 2024-04-23 20:07 ` Arnaldo Carvalho de Melo 1 sibling, 0 replies; 10+ messages in thread From: Arnaldo Carvalho de Melo @ 2024-04-23 20:07 UTC (permalink / raw) To: Andy Shevchenko Cc: linux-kernel, Willy Tarreau, Thomas Weißschuh, Andrew Morton, willy, Namhyung Kim On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote: > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote: > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote: > > > It seems tons of the code in tools include linux/limits.h. But I haven't found > > > where do we copy it. Any pointers? > > > Based on the discussion 20220603183231.15159C385A9@smtp.kernel.org. <SNIP> > > But then is for building tools/, not the kernel, right? The discussion > > you said this question was based on is about changing > > include/linux/xarray.h, a kernel file, so should really be including > > just kernel headers, files in the kernel source tree, outside tools/, I > > don't see where what tools/ uses to build is relevant here? Can you > > please elaborate? > > I believe the tool in question is tools/testing/radix-tree/xarray.c. And it is including stuff from the kernel directly, something we stopped doing long ago in tools/ to avoid breakage when a kernel developer changes kernel code: ⬢[acme@toolbox perf-tools-next]$ cd tools/testing/radix-tree/ ⬢[acme@toolbox radix-tree]$ grep -A1 -- -I Makefile # SPDX-License-Identifier: GPL-2.0 CFLAGS += -I. -I../../include -I../../../lib -g -Og -Wall \ -D_LGPL_SOURCE -fsanitize=address -fsanitize=undefined ⬢[acme@toolbox radix-tree]$ realpath ../../include /home/acme/git/perf-tools-next/tools/include So far so good, no kernel files included, only tools/ stuff, but then: ⬢[acme@toolbox radix-tree]$ grep xarray *.c | grep include xarray.c:#include "../../../lib/xarray.c" xarray.c:#include "../../../lib/test_xarray.c" ⬢[acme@toolbox radix-tree]$ realpath ../../../lib/xarray.c /home/acme/git/perf-tools-next/lib/xarray.c ⬢[acme@toolbox radix-tree]$ And this in turn will: ⬢[acme@toolbox radix-tree]$ grep ^#include ../../../lib/xarray.c #include <linux/bitmap.h> #include <linux/export.h> #include <linux/list.h> #include <linux/slab.h> #include <linux/xarray.h> #include "radix-tree.h" ⬢[acme@toolbox radix-tree]$ Includes kernel headers, as it _is_ kernel code. Perhaps since it does that we need to add -I../../../include to the include path to really include kernel headers? ⬢[acme@toolbox radix-tree]$ pwd /home/acme/git/perf-tools-next/tools/testing/radix-tree ⬢[acme@toolbox radix-tree]$ realpath ../../../include /home/acme/git/perf-tools-next/include ⬢[acme@toolbox radix-tree]$ - Arnaldo ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-04-24 14:46 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-04-23 18:58 limits.h in tools/ Andy Shevchenko 2024-04-23 19:22 ` Arnaldo Carvalho de Melo 2024-04-23 19:29 ` Andy Shevchenko 2024-04-23 19:30 ` Andy Shevchenko 2024-04-24 13:46 ` Liam R. Howlett 2024-04-24 14:19 ` Andy Shevchenko 2024-04-24 14:40 ` Liam R. Howlett 2024-04-24 14:46 ` Liam R. Howlett 2024-04-24 14:19 ` Arnaldo Carvalho de Melo 2024-04-23 20:07 ` Arnaldo Carvalho de Melo
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.