lkml.org 
[lkml]   [2024]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2024-04-24 16:20    [W:0.091 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site