From: Shuah Khan <email@example.com> To: Alexei Starovoitov <firstname.lastname@example.org>, Shuah Khan <email@example.com> Cc: Daniel Borkmann <firstname.lastname@example.org>, Thomas Meyer <email@example.com>, firstname.lastname@example.org, email@example.com, Networking <firstname.lastname@example.org>, Shuah Khan <email@example.com> Subject: Re: selftests/bpf doesn't compile Date: Fri, 15 Sep 2017 11:00:31 -0600 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20170915160253.q3x5j7hfkxxh2g6w@ast-mbp> On 09/15/2017 10:02 AM, Alexei Starovoitov wrote: > On Thu, Sep 14, 2017 at 09:33:48AM -0600, Shuah Khan wrote: >> Hi Alexei and Daniel, >> >> bpf test depends on clang and fails to compile when >> >> ------------------------------------------------------ >> make -C tools/testing/selftests/bpf run_tests >> >> >> make: clang: Command not found >> Makefile:39: recipe for target '.linux-kselftest/tools/testing/selftests/bpf/test_pkt_access.o' failed >> make: *** [./linux-kselftest/tools/testing/selftests/bpf/test_pkt_access.o] Error 127 >> make: Leaving directory '.linux-kselftest/tools/testing/selftests/bpf' >> >> With "make TARGETS=bpf kselftest" it fails earlier: >> >> >> make: Entering directory './linux-kselftest/tools/lib/bpf' >> Makefile:40: tools/scripts/Makefile.arch: No such file or directory >> Makefile:84: tools/build/Makefile.feature: No such file or directory >> Makefile:143: tools/build/Makefile.include: No such file or directory >> make: *** No rule to make target 'tools/build/Makefile.include'. Stop. >> make: Leaving directory '.linux-kselftest/tools/lib/bpf' >> Makefile:34: recipe for target './linux-kselftest/tools/testing/selftests/bpf/libbpf.a' failed >> make: *** [./linux-kselftest/tools/testing/selftests/bpf/libbpf.a] Error 2 >> make: Leaving directory './linux-kselftest/tools/testing/selftests/bpf' >> Makefile:69: recipe for target 'all' failed >> make: *** [all] Error 2 >> Makefile:1190: recipe for target 'kselftest' failed >> make: *** [kselftest] Error 2 >> >> -------------------------------------------------------------- >> >> Is bpf test intended to be run in kselftest run? The clang dependency might >> not be met on majority of the systems. Is this a hard dependency?? > > It is a hard dependency and clang should be present on majority of the systems. > More details are in samples/bpf/README.rst > which was written long ago. Nowadays apt-get/yum will install clang > with bpf support builtin. Thanks for the clarification. > >> Would it make sense to create a special target for bpf test? We do have a few >> tests that do that now. >> >> TARGETS_HOTPLUG = cpu-hotplug >> TARGETS_HOTPLUG += memory-hotplug >> >> I could add a special target for bpf TARGET_BPF perhaps and exclude it from >> the run_test> > I'm not sure what was the motivation to exclude hotplug from default testing, These are considered a bit more disruptive and were excluded a while back. These take cpus and memory on and off-line. Also require root access. So even if they are included in the regular run, these won't run. > since I think it diminishes the value of selftests overall. I agree. We do have some timer tests that are destructive/stress that et run using a special target. It is the idea that if somebody wants to test all them, there is a way to do that. In any case, I didn't think bpf falls into this category of tests that belong in the destructive category. I am looking to understand the failures and your take on those. > Not running all tests all the time risks breaking them It is balance of providing a choice to users if they don't want to run destructive tests. For example, suspend test which requires root access. So the idea is for users to run these by choice as opposed to running them in the normal run and cause disruption. > selftest makefile refactoring broke selftests/bpf in the past, Yeah. We have had some fallout from the KBUILD_OUTPUT work that didn't take all the use-cases into account and tests that require custom builds such as the bpf tests. Using common build infrastructure doesn't work for all tests. Looks like there are other patches that went in later with lcap work. > so I strongly suggest to install clang and make sure the tests are passing > on the test servers You will have to request kernelci, stable, and It is a choice to be made by kernelci/zero-day folks. otherwise we'd need to move selftests/bpf out of > selftests to avoid further headaches for us when selftests infra keeps > changing. > Let's not go to extreme options. :) I am merely looking for more information and trying to understand the dependencies for this test. Let's look for a constructive option to fix the build failures I am seeing. The first failure due to clang dependency is not a problem. The second one in the case of "make kselftest" is the one that requires some work when bpf make is run from the main Makefile. A lots of users run tests using the kselftest target from the mail Makefile. hence I would like to get this working, so it would be easier to run this test on test servers. thanks, -- Shuah
next prev parent reply other threads:[~2017-09-15 17:00 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-08 11:19 [PATCH] selftests/bpf: Make bpf_util work on uniprocessor systems Thomas Meyer 2017-09-08 23:01 ` Alexei Starovoitov 2017-09-08 23:05 ` Daniel Borkmann 2017-09-14 15:01 ` Shuah Khan 2017-09-14 15:33 ` selftests/bpf doesn't compile Shuah Khan 2017-09-15 16:02 ` Alexei Starovoitov 2017-09-15 16:58 ` Edward Cree 2017-09-15 18:07 ` Alexei Starovoitov 2017-09-15 18:23 ` Daniel Borkmann 2017-09-15 18:48 ` Daniel Borkmann 2017-09-15 22:41 ` Shuah Khan 2017-09-18 13:31 ` Daniel Borkmann 2017-09-15 17:00 ` Shuah Khan [this message] 2017-09-15 17:44 ` Shuah Khan 2017-09-15 18:14 ` Alexei Starovoitov 2017-09-15 22:32 ` Shuah Khan 2019-01-04 17:16 ` Geert Uytterhoeven 2019-01-04 19:07 ` shuah 2017-09-19 14:45 ` [PATCH] selftests/bpf: Make bpf_util work on uniprocessor systems Shuah Khan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: selftests/bpf doesn'\''t compile' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).