From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: "Andy Shevchenko" <andriy.shevchenko@intel.com>,
linux-kernel@vger.kernel.org, "Willy Tarreau" <w@1wt.eu>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Andrew Morton" <akpm@linux-foundation.org>,
willy@infradead.org, "Namhyung Kim" <namhyung@kernel.org>
Subject: Re: limits.h in tools/
Date: Wed, 24 Apr 2024 11:19:52 -0300 [thread overview]
Message-ID: <ZikVCCJRKImZ3zWB@x1> (raw)
In-Reply-To: <t2n5aj7orslsewknx6vmlf7t4wbnj3u6cabrjjfaptexb64fzn@rbjhcj3uwrkg>
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
next prev parent reply other threads:[~2024-04-24 14:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2024-04-23 20:07 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZikVCCJRKImZ3zWB@x1 \
--to=acme@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=namhyung@kernel.org \
--cc=w@1wt.eu \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox