RE: [PATCH] selftests: add build/cross-build dependency check script

["Bird, Tim" <Tim.Bird@xxxxxxxx>]

> -----Original Message-----
> From: linux-kselftest-owner@xxxxxxxxxxxxxxx <linux-kselftest-owner@xxxxxxxxxxxxxxx> On Behalf Of Randy Dunlap
> 
> On 4/14/20 2:22 PM, Shuah Khan wrote:
> > -CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ $(MOUNT_CFLAGS)
> > -LDLIBS += $(MOUNT_LDLIBS)
> > +CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ $(VAR_CFLAGS)
> > +LDLIBS += $(VAR_LDLIBS)
> 
> 
> (1) Can that series of ../../../.. be replaced by $(objtree)?
> If so, that would be much cleaner IMO.

kselftests doesn't set $(objtree) when it is run directly
(ie make -C tools/testing/selftests)

I had my own solution which was to use KBUILD_OUTPUT, like so:
This was a patch in my queue, that I didn't send in because I wasn't
very happy with it.  I was still considering alternatives.

---------------- (patch)
Subject: [PATCH] selftests/vm: use includes from KBUILD_OUTPUT directory

The Makefile for the vm tests was specifying a relative path
(in the source directory) for accessing include files.  This
doesn't work when the headers files are placed in another
directory (with O= or KBUILD_OUTPUT).  It may appear to work,
but ends up using includes from the host machine, which may
not match the kernel source being compiled against.

Without this change, when the program userfaultfd.c was
compiled, it generated errors like the following:

    userfaultfd.c:267:21: error: 'UFFD_API_RANGE_IOCTLS_BASIC' undeclared
    here (not in a function)
      .expected_ioctls = UFFD_API_RANGE_IOCTLS_BASIC,
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    userfaultfd.c: In function 'uffd_poll_thread':
    userfaultfd.c:529:8: error: 'UFFD_EVENT_FORK' undeclared (first use in
    this function)
       case UFFD_EVENT_FORK:
            ^~~~~~~~~~~~~~~
    userfaultfd.c:529:8: note: each undeclared identifier is reported only
    once for each function it appears in
    userfaultfd.c:531:18: error: 'union <anonymous>' has no member named
    'fork'
        uffd = msg.arg.fork.ufd;
                      ^

Change the CFLAGS definition in the Makefile to reference
KBUILD_OUTPUT.

Signed-off-by: Tim Bird <tim.bird@xxxxxxxx>
---
 tools/testing/selftests/vm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
index 7f9a8a8..0208659 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -3,7 +3,7 @@
 uname_M := $(shell uname -m 2>/dev/null || echo not)
 ARCH ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/')
 
-CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS)
+CFLAGS = -Wall -I $(KBUILD_OUTPUT)/usr/include $(EXTRA_CFLAGS)
 LDLIBS = -lrt
 TEST_GEN_FILES = compaction_test
 TEST_GEN_FILES += gup_benchmark
-- 
2.1.4
-------- (end patch)

The reason I wasn't happy is that this required another patch to
tools/testing/Makefile to make sure KBUILD_OUTPUT was always
set.  I got sidetracked on the make headers_install issue, and didn't
finish this up.  Sorry about that. (See below for the headers_install issue).

> 
> (2) I can't find anything that checks that ../../../../usr/include exists
> (or has been installed via 'make headers_install').  Or anything that
> requires that CONFIG_HEADERS_INSTALL be set/enabled.  Well, other than
> a Makefile error, but that's not a nice way to find out.

The kselftest handling of headers_install is quite confusing.  There is a
dependency in the top-level Makefile that ends up causing a vmlinux build,
even if you just finished doing a headers_install recently (at least the way
that it is called by kselftest, and in certain build configurations that I am seeing
with my testing.)

I suspect that we don't have clean separation of kernel headers for the
kernel under test, from the host machine's kernel header files, for builds
of kselftest programs.  But I ran out of time to tease this out.
  -- Tim

> 
> Preferably we would have some Kconfig check/enforcement or at least some
> documentation.
> 
> Thoughts?
> 
> thanks.
> --
> ~Randy