All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"Andrii Nakryiko" <andriin@fb.com>,
	"Doug Ledford" <dledford@redhat.com>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jiri Olsa" <jolsa@redhat.com>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Shuah Khan" <shuah@kernel.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	clang-built-linux@googlegroups.com, brouer@redhat.com
Subject: Re: [PATCH bpf-next v3 00/11] tools: Use consistent libbpf include paths everywhere
Date: Fri, 17 Jan 2020 09:57:21 +0100	[thread overview]
Message-ID: <20200117095721.0030f414@carbon> (raw)
In-Reply-To: <20200117041431.h7vvc32fungenyhg@ast-mbp.dhcp.thefacebook.com>

On Thu, 16 Jan 2020 20:14:32 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Thu, Jan 16, 2020 at 02:22:11PM +0100, Toke Høiland-Jørgensen wrote:
> > The recent commit 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are
> > taken from selftests dir") broke compilation against libbpf if it is installed
> > on the system, and $INCLUDEDIR/bpf is not in the include path.
> > 
> > Since having the bpf/ subdir of $INCLUDEDIR in the include path has never been a
> > requirement for building against libbpf before, this needs to be fixed. One
> > option is to just revert the offending commit and figure out a different way to
> > achieve what it aims for.   
> 
> The offending commit has been in the tree for a week. So I applied Andrii's
> revert of that change. It reintroduced the build dependency issue, but we lived
> with it for long time, so we can take time to fix it cleanly.
> I suggest to focus on that build dependency first.
> 
> > However, this series takes a different approach:
> > Changing all in-tree users of libbpf to consistently use a bpf/ prefix in
> > #include directives for header files from libbpf.  
> 
> I'm not sure it's a good idea. It feels nice, but think of a message we're
> sending to everyone. We will get spamed with question: does bpf community
> require all libbpf users to use bpf/ prefix ? What should be our answer?

The answer should be: Yes. When libbpf install the header files the are
installed under bpf/ prefix.  It is very confusing that samples and
selftests can include libbpf.h without this prefix. Even worse
including "bpf.h" pickup the libbpf version bpf/bpf.h, which have
caused confusion.  The only reason for the direct "libbpf.h" include is
historical, as there used-to-be a local file for that.


> Require or recommend? If require.. what for? It works as-is. If recommend then
> why suddenly we're changing all files in selftests and samples?
> There is no good answer here. I think we should leave the things as-is.

I strongly believe we should correct this.  It doesn't make sense that
someone copying out a sample or selftests, into a git-submodule libbpf
(or distro installed libbpf-devel) have to understand that they have to
update the include path for all the libbpf header files.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


  reply	other threads:[~2020-01-17  8:57 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 13:22 [PATCH bpf-next v3 00/11] tools: Use consistent libbpf include paths everywhere Toke Høiland-Jørgensen
2020-01-16 13:22 ` [PATCH bpf-next v3 01/11] samples/bpf: Don't try to remove user's homedir on clean Toke Høiland-Jørgensen
2020-01-16 13:22 ` [PATCH bpf-next v3 02/11] tools/bpf/runqslower: Fix override option for VMLINUX_BTF Toke Høiland-Jørgensen
2020-01-16 18:54   ` Andrii Nakryiko
2020-01-17  9:44     ` Toke Høiland-Jørgensen
2020-01-16 13:22 ` [PATCH bpf-next v3 03/11] selftests: Pass VMLINUX_BTF to runqslower Makefile Toke Høiland-Jørgensen
2020-01-16 18:56   ` Andrii Nakryiko
2020-01-16 13:22 ` [PATCH bpf-next v3 04/11] tools/runqslower: Use consistent include paths for libbpf Toke Høiland-Jørgensen
2020-01-16 21:56   ` Andrii Nakryiko
2020-01-17  9:46     ` Toke Høiland-Jørgensen
2020-01-16 13:22 ` [PATCH bpf-next v3 05/11] selftests: " Toke Høiland-Jørgensen
2020-01-16 21:57   ` Andrii Nakryiko
2020-01-16 13:22 ` [PATCH bpf-next v3 06/11] bpftool: " Toke Høiland-Jørgensen
2020-01-16 22:21   ` Andrii Nakryiko
2020-01-16 13:22 ` [PATCH bpf-next v3 07/11] perf: " Toke Høiland-Jørgensen
2020-01-16 22:22   ` Andrii Nakryiko
2020-01-16 13:22 ` [PATCH bpf-next v3 08/11] samples/bpf: " Toke Høiland-Jørgensen
2020-01-16 22:23   ` Andrii Nakryiko
2020-01-16 13:22 ` [PATCH bpf-next v3 09/11] selftests: Remove tools/lib/bpf from include path Toke Høiland-Jørgensen
2020-01-16 22:41   ` Andrii Nakryiko
2020-01-16 23:05     ` Andrii Nakryiko
2020-01-17  9:50       ` Toke Høiland-Jørgensen
2020-01-17  9:49     ` Toke Høiland-Jørgensen
2020-01-16 13:22 ` [PATCH bpf-next v3 10/11] tools/runqslower: " Toke Høiland-Jørgensen
2020-01-16 22:44   ` Andrii Nakryiko
2020-01-16 13:22 ` [PATCH bpf-next v3 11/11] libbpf: Fix include of bpf_helpers.h when libbpf is installed on system Toke Høiland-Jørgensen
2020-01-16 22:43   ` Andrii Nakryiko
2020-01-17  4:14 ` [PATCH bpf-next v3 00/11] tools: Use consistent libbpf include paths everywhere Alexei Starovoitov
2020-01-17  8:57   ` Jesper Dangaard Brouer [this message]
2020-01-17  9:58     ` Toke Høiland-Jørgensen

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=20200117095721.0030f414@carbon \
    --to=brouer@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dledford@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=kafai@fb.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=shuah@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=toke@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 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.