Messages in this thread | | | Date | Wed, 24 Apr 2024 11:19:52 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: limits.h in tools/ |
| |
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
| |