Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Mark Brown <broonie@kernel.org>
Cc: Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Daniel Diaz <daniel.diaz@linaro.org>,
	Veronika Kabatova <vkabatov@redhat.com>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	Guillaume Tucker <guillaume.tucker@collabora.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] selftests: Skip BPF seftests by default
Date: Thu, 10 Dec 2020 16:41:33 -0700	[thread overview]
Message-ID: <7e0ca62b-ff63-7d26-355f-c49e98a0ef36@linuxfoundation.org> (raw)
In-Reply-To: <20201210191103.kfrna27kv3xwnshr@ast-mbp>

On 12/10/20 12:11 PM, Alexei Starovoitov wrote:
> On Thu, Dec 10, 2020 at 06:52:33PM +0000, Mark Brown wrote:
>> The BPF selftests have build time dependencies on cutting edge versions
>> of tools in the BPF ecosystem including LLVM which are more involved
>> to satisfy than more typical requirements like installing a package from
>> your distribution.  This causes issues for users looking at kselftest in
>> as a whole who find that a default build of kselftest fails and that
>> resolving this is time consuming and adds administrative overhead.  The
>> fast pace of BPF development and the need for a full BPF stack to do
>> substantial development or validation work on the code mean that people
>> working directly on it don't see a reasonable way to keep supporting
>> older environments without causing problems with the usability of the
>> BPF tests in BPF development so these requirements are unlikely to be
>> relaxed in the immediate future.
>>
>> There is already support for skipping targets so in order to reduce the
>> barrier to entry for people interested in kselftest as a whole let's use
>> that to skip the BPF tests by default when people work with the top
>> level kselftest build system.  Users can still build the BPF selftests
>> as part of the wider kselftest build by specifying SKIP_TARGETS,
>> including setting an empty SKIP_TARGETS to build everything.  They can
>> also continue to build the BPF selftests individually in cases where
>> they are specifically focused on BPF.
>>
>> This isn't ideal since it means people will need to take special steps
>> to build the BPF tests but the dependencies mean that realistically this
>> is already the case to some extent and it makes it easier for people to
>> pick up and work with the other selftests which is hopefully a net win.
>>
>> Signed-off-by: Mark Brown <broonie@kernel.org>
>> ---
>>   tools/testing/selftests/Makefile | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>> index afbab4aeef3c..8a917cb4426a 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -77,8 +77,10 @@ TARGETS += zram
>>   TARGETS_HOTPLUG = cpu-hotplug
>>   TARGETS_HOTPLUG += memory-hotplug
>>   
>> -# User can optionally provide a TARGETS skiplist.
>> -SKIP_TARGETS ?=
>> +# User can optionally provide a TARGETS skiplist.  By default we skip
>> +# BPF since it has cutting edge build time dependencies which require
>> +# more effort to install.
>> +SKIP_TARGETS ?= bpf
> 
> I'm fine with this, but I'd rather make an obvious second step right away
> and move selftests/bpf into a different directory.
> 

Why is this an obvious second step? If people want to run bpf, they can
build and run. How does moving it out of selftests directory help? It
would become harder on users that want to run the test.

I don't support moving bpf out of selftests directory in the interest
of Linux kernel quality and validation.

Let's think big picture and kernel community as a whole.

thanks,
-- Shuah

  reply	other threads:[~2020-12-10 23:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 18:52 [PATCH] selftests: Skip BPF seftests by default Mark Brown
2020-12-10 19:11 ` Alexei Starovoitov
2020-12-10 23:41   ` Shuah Khan [this message]
2020-12-11 12:46     ` Mark Brown
2020-12-16 22:05 ` Seth Forshee
2020-12-17 13:07   ` Mark Brown
2020-12-17 15:53     ` Shuah Khan
2020-12-17 18:32       ` 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 \
    --in-reply-to=7e0ca62b-ff63-7d26-355f-c49e98a0ef36@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=broonie@kernel.org \
    --cc=daniel.diaz@linaro.org \
    --cc=daniel@iogearbox.net \
    --cc=guillaume.tucker@collabora.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=khilman@baylibre.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=vkabatov@redhat.com \
    --cc=yhs@fb.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox