All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Christoph Hellwig <hch@lst.de>
Cc: Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	bpf@vger.kernel.org
Subject: Re: BPF selftests build failures
Date: Mon, 20 Jul 2020 20:54:53 -0600	[thread overview]
Message-ID: <a0afbf75-5e48-9b18-214e-e9d6c7933aef@gmail.com> (raw)
In-Reply-To: <20200720204152.w7h3zmwtbjsuwgie@ast-mbp.dhcp.thefacebook.com>

On 7/20/20 2:41 PM, Alexei Starovoitov wrote:
> On Mon, Jul 20, 2020 at 10:09:43AM +0200, Christoph Hellwig wrote:
>> Hi BPF and selftest maintainers.  I get a very strange failure
>> when trying to build the bpf selftests on current net-next master:
>>
>> hch@brick:~/work/linux/tools/testing/selftests/bpf$ make
>>   GEN      vmlinux.h
>> Error: failed to load BTF from /home/hch/work/linux/vmlinux: No such file or directory
> 
> That's bpftool complaining that BTF is not present in vmlinux.
> You need CONFIG_DEBUG_INFO_BTF=y and pahole >= v1.16
> You also need llvm 10 to build bpf progs.
> 

These never ending bumps to required versions to build kernels and bpf
code are not friendly to users. Until a recent commit I was able to use
Ubuntu 20.04 for bpf development and testing (e.g., the recent devmap
changes). Ubuntu 20.04 is an LTS OS released just 3 months ago with
pahole 1.15 and llvm 10. Now with v5.8-next 20.04 is out of date.

These hard requirements are making BTF inaccessible to average users by
*requiring* them to constantly chase new build versions. At this point I
can no longer point potential BPF/XDP users to this latest OS and say
try it out. Any instructions I write for getting started will be out of
date in some arbitrarily short period of time.

Worst, it is not even feature based within BTF; it is all or nothing.
ie., try to use 5.8-next with Ubuntu 20.04 and you lose all of BTF for
all use cases, not just some recently added feature.

If you want people to adopt this tech, you need to make it easier to use.

  reply	other threads:[~2020-07-21  2:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20  8:09 BPF selftests build failures Christoph Hellwig
2020-07-20 20:41 ` Alexei Starovoitov
2020-07-21  2:54   ` David Ahern [this message]
2020-07-21  5:24   ` Christoph Hellwig
2020-07-21  7:04   ` Christoph Hellwig

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=a0afbf75-5e48-9b18-214e-e9d6c7933aef@gmail.com \
    --to=dsahern@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hch@lst.de \
    --cc=shuah@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.