Re: [PATCH v4] selftests: add headers_install to lib.mk

[Anders Roxell]

On Tue, 7 Aug 2018 at 04:33, Masahiro Yamada
<yamada.masahiro@xxxxxxxxxxxxx> wrote:
>
> 2018-08-07 2:03 GMT+09:00 Shuah Khan <shuah@xxxxxxxxxx>:
> > Hi Anders,
> >
> > On 07/25/2018 10:08 AM, Anders Roxell wrote:
> >> On Tue, 24 Jul 2018 at 19:11, Shuah Khan <shuah@xxxxxxxxxx> wrote:
> >>>
> >>> On 07/23/2018 02:49 PM, Anders Roxell wrote:
> >>>> On Thu, 7 Jun 2018 at 13:09, Anders Roxell <anders.roxell@xxxxxxxxxx> wrote:
> >>>>>
> >>>>> If the kernel headers aren't installed we can't build all the tests.
> >>>>> Add a new make target rule 'khdr' in the file lib.mk to generate the
> >>>>> kernel headers and that gets include for every test-dir Makefile that
> >>>>> includes lib.mk If the testdir in turn have its own sub-dirs the
> >>>>> top_srcdir needs to be set to the linux-rootdir to be able to generate
> >>>>> the kernel headers.
> >>>>>
> >>>>> Signed-off-by: Anders Roxell <anders.roxell@xxxxxxxxxx>
> >>>>> Reviewed-by: Fathi Boudra <fathi.boudra@xxxxxxxxxx>
> >>>>> ---
> >>>>>  Makefile                                           | 14 +-------------
> >>>>>  scripts/subarch.include                            | 13 +++++++++++++
> >>>>>  tools/testing/selftests/android/Makefile           |  2 +-
> >>>>>  tools/testing/selftests/android/ion/Makefile       |  2 ++
> >>>>>  tools/testing/selftests/futex/functional/Makefile  |  1 +
> >>>>>  tools/testing/selftests/gpio/Makefile              |  7 ++-----
> >>>>>  tools/testing/selftests/kvm/Makefile               |  7 ++-----
> >>>>>  tools/testing/selftests/lib.mk                     | 12 ++++++++++++
> >>>>>  tools/testing/selftests/net/Makefile               |  1 +
> >>>>>  .../selftests/networking/timestamping/Makefile     |  1 +
> >>>>>  tools/testing/selftests/vm/Makefile                |  4 ----
> >>>>>  11 files changed, 36 insertions(+), 28 deletions(-)
> >>>>>  create mode 100644 scripts/subarch.include
> >>>>>
> >>>>> diff --git a/Makefile b/Makefile
> >>>>> index 6b9aea95ae3a..8050072300fa 100644
> >>>>> --- a/Makefile
> >>>>> +++ b/Makefile
> >>>>> @@ -286,19 +286,7 @@ KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
> >>>>>  KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
> >>>>>  export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
> >>>>>
> >>>>> -# SUBARCH tells the usermode build what the underlying arch is.  That is set
> >>>>> -# first, and if a usermode build is happening, the "ARCH=um" on the command
> >>>>> -# line overrides the setting of ARCH below.  If a native build is happening,
> >>>>> -# then ARCH is assigned, getting whatever value it gets normally, and
> >>>>> -# SUBARCH is subsequently ignored.
> >>>>> -
> >>>>> -SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> >>>>> -                                 -e s/sun4u/sparc64/ \
> >>>>> -                                 -e s/arm.*/arm/ -e s/sa110/arm/ \
> >>>>> -                                 -e s/s390x/s390/ -e s/parisc64/parisc/ \
> >>>>> -                                 -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> >>>>> -                                 -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> >>>>> -                                 -e s/riscv.*/riscv/)
> >>>>> +include scripts/subarch.include
> >>>
> >>> What is the reason for this SUBARCH block move to to scripts/subarch.include?
> >>> Is this necessary for adding headers install dependency to lib.mk?
> >>
> >> This is needed to create headers for cross build.
> >>
> >
> > I am sorry for the delay on this patch. I am going to get this into 4.19.
> > If anybody has objections, please let me.
> >
> > Anders! Will be able to rebase the patch and send me the latest. I think
> > I have Acks from kvm, android, and vm so far.
> >
>
>
> I may be missing something about the tools/ directory,
> but why isn't it like this?
>
>
> kselftest: headers_install
>         $(Q)$(MAKE) -C $(srctree)/tools/testing/selftests run_tests

That wont work if you cross compile, since you wont run the tests
where you build them.
Then you can argue that we should break it up in a build and run rule.
However, my understanding how people just build and run the the tests
for that particular subsystem that they develop for, like:
make -C tools/testing/selftests/<subsystem>/

Cheers,
Anders