Re: The "make headers" requirement, revisited: [PATCH v3 3/3] selftests: pidfd: add tests for PIDFD_SELF_*

[Shuah Khan <skhan@linuxfoundation.org>]

On 10/17/24 10:47, John Hubbard wrote:
> 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,

Posting this on this thread as well -

Peter, John,

There seems to be confusion regarding  KHDR_INCLUDES. Tests don't have
to use KHDR_INCLUDES if they don't want to.

There are 4623 test Makefiles (excluding the main Makefile) under selftests/.
Out of those 73 Makefiles reference KHDR_INCLUDES exported by lib.mk and
selftests/Makefile. The rest are happy with system headers.

The support for this KHDR_INCLUDES was added just for the case when a new
test depends on header change. This is the reason why only a few
test Makefiles use it. When test rings ran into issues related to
dependencies between header changes, we recommended installing headers
to solve the problem and introduced KHDR_INCLUDES so test Makefiles
can use it in their Makefiles overriding the framework defaults.

If your test doesn't need it, you can simply stop referencing it or
use the approach used in mm test.

It is a manual step. Works well for developers who know what they are doing.
This isn't ideal for test rings. This isn't an ideal solution really.
It works for the mm developers.

# In order to use newer items that haven't yet been added to the user's system
# header files, add $(TOOLS_INCLUDES) to the compiler invocation in each
# each selftest.
# You may need to add files to that location, or to refresh an existing file. In
# order to do that, run "make headers" from $(top_srcdir), then copy the
# header file that you want from $(top_srcdir)/usr/include/... , to the matching
# subdir in $(TOOLS_INCLUDE).
TOOLS_INCLUDES := -isystem $(top_srcdir)/tools/include/uapi

The issues Peter is seeing regarding KHDR_INCLUDES in the following
tests can be easily fixed by simply changing the test Makefile. These
aren't framework related.

kvm/Makefile.kvm:    -I ../rseq -I.. $(EXTRA_CFLAGS) $(KHDR_INCLUDES)
x86/Makefile:CFLAGS := -O2 -g -std=gnu99 -pthread -Wall $(KHDR_INCLUDES)
futex/functional/Makefile:INCLUDES := -I../include -I../../ $(KHDR_INCLUDES)
futex/functional/Makefile:CFLAGS := $(CFLAGS) -g -O2 -Wall -pthread $(INCLUDES) $(KHDR_INCLUDES)

You can make the change to remove the reference to KHDR_INCLUDES.
If don't have the time/bandwidth to do it, I will take care of it.

If test build fails, you can then figure out how to address that.
Hopefully build issues related to header changes are infrequent.

thanks,
-- Shuah