[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3687348f-7ee0-4fe1-a953-d5a2edd02ce8@nvidia.com>
Date: Thu, 17 Oct 2024 09:47:43 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Shuah Khan <skhan@...uxfoundation.org>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Christian Brauner <christian@...uner.io>,
Peter Zijlstra <peterz@...radead.org>
Cc: Shuah Khan <shuah@...nel.org>, "Liam R . Howlett"
<Liam.Howlett@...cle.com>, Suren Baghdasaryan <surenb@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>, pedro.falcato@...il.com,
linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org, Oliver Sang <oliver.sang@...el.com>
Subject: Re: The "make headers" requirement, revisited: [PATCH v3 3/3]
selftests: pidfd: add tests for PIDFD_SELF_*
On 10/17/24 9:33 AM, Shuah Khan wrote:
> On 10/16/24 20:01, John Hubbard wrote:
>> On 10/16/24 1:00 PM, Shuah Khan wrote:
>>> On 10/16/24 04:20, Lorenzo Stoakes wrote:
...
>> The requirement to do "make headers" is not a keeper. Really.
>
> The reason we added the requirement to avoid duplicate defines
> such as this one added to kselftest source files. These are
> error prone and hard to resolve.
>
> In some cases, these don't become uapi and don't make it into
> system headers. selftests are in a category of depending on
> kernel headers to be able to test some features.
>
> Getting rid of this dependency mean, tests will be full of local
> defines such as this one which will become unmanageable overtime.
Not if we do it correctly...Please do look at the reference I provided
for how that works. Here is is again: [1].
The basic idea, which has been discussed and reviewed, is to take
very occasional snapshots and drop them into a static location where
they are available for kselftests, without disurbing other things:
$(top_srcdir)/tools/include/uapi
This has worked well so far.
>
> The discussion should be: "How do we get rid of the dependency without
> introducing local defines?" not just "Let's get rid of the dependency"
>
Yes. Good. We are apparently in violent agreement, because a few lines
above,
I wrote:
The requirement to do "make headers" is not a keeper.
The "make headers" is the problem, not the fact that we need to depend
on various includes. And so the solution stops requiring "make headers".
It gets the includes from a less volatile location.
Yes?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e076eaca5906
thanks,
--
John Hubbard
Powered by blists - more mailing lists