Received-SPF: pass (google.com: domain of linux-kernel+bounces-157063-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 24 Apr 2024 11:19:52 -0300
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 =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
	Andrew Morton <akpm@linux-foundation.org>, willy@infradead.org,
	Namhyung Kim <namhyung@kernel.org>
Subject: Re: limits.h in tools/
Message-ID: <ZikVCCJRKImZ3zWB@x1>
References: <ZigEvxn0-70og0H1@smile.fi.intel.com>
 <ZigKWZKY6kq-w0Tp@x1>
 <ZigMG8ZsBryO57zz@smile.fi.intel.com>
 <ZigMa2GqF_HN39oz@smile.fi.intel.com>
 <t2n5aj7orslsewknx6vmlf7t4wbnj3u6cabrjjfaptexb64fzn@rbjhcj3uwrkg>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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