LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Jiri Olsa" <jolsa@kernel.org>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Michael Petlan" <mpetlan@redhat.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"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>,
	"Quentin Monnet" <quentin.monnet@netronome.com>
Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically
Date: Wed, 4 Dec 2019 19:17:20 -0800
Message-ID: <20191205031718.ax46kfv55zauuopt@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20191204181028.6cdb40d4@cakuba.netronome.com>

On Wed, Dec 04, 2019 at 06:10:28PM -0800, Jakub Kicinski wrote:
> On Wed, 4 Dec 2019 17:09:32 -0800, Alexei Starovoitov wrote:
> > On Wed, Dec 04, 2019 at 04:23:48PM -0800, Jakub Kicinski wrote:
> > > On Wed, 4 Dec 2019 15:39:49 -0800, Alexei Starovoitov wrote:  
> > > > > Agreed. Having libbpf on GH is definitely useful today, but one can hope
> > > > > a day will come when distroes will get up to speed on packaging libbpf,
> > > > > and perhaps we can retire it? Maybe 2, 3 years from now? Putting
> > > > > bpftool in the same boat is just more baggage.    
> > > > 
> > > > Distros should be packaging libbpf and bpftool from single repo on github.
> > > > Kernel tree is for packaging kernel.  
> > > 
> > > Okay, single repo on GitHub:
> > > 
> > > https://github.com/torvalds/linux  
> > 
> > and how will you git submodule only libbpf part of kernel github into bcc
> > and other projects?
> 
> Why does bcc have to submodule libbpf? Is it in a "special
> relationship" with libbpf as well? 
> 
> dnf/apt install libbpf
> 
> Or rather:
> 
> dnf/apt install bcc
> 
> since BCC's user doesn't care about dependencies. The day distroes
> started packaging libbpf and bpftool the game has changed.

have you ever built bcc ? or bpftrace?
I'm not sure how to answer such 'suggestion'.

> Please accept iproute2 as an example of a user space toolset closely
> related to the kernel. If kernel release model and process made no
> sense in user space, why do iproute2s developers continue to follow it
> for years? 

imo iproute2 is an example how things should not be run.
But that's a very different topic.

> > Packaging is different.
> 
> There are mostly disadvantages, but the process should be well known.
> perf has been packaged for years.

perf was initially seen as something that should match kernel one to one.
yet it diverged over years. I think it's a counter example.

> What do you mean? I've sure as hell sent patches to net with Fixes tags

which was complete waste of time for people who were sending these
patches, for maintainers who applied them and for all stables folks
who carried them into kernel stable releases.
Not a single libbpf build was made out of those sources.

> S-o-B and all that jazz for libbpf and bpftool.

Many open source projects use SOB. It's not kernel specific.

> 
> > Even coding style is different.
> 
> Is it? You mean the damn underscores people are making fun of? :/

Are you trolling? Do you understand why __ is there?

> libbpf doesn't have a roadmap either, 

I think you're contrasting that with kernel and saying
that kernel has a roadmap ? What is kernel roadmap?

> it's not really a full-on project
> on its own. What's 0.1.0 gonna be?

whenever this bpf community decides to call it 0.1.0.

> Besides stuff lands in libbpf before it hits a major kernel release.
> So how are you gonna make libbpf releases independently from kernel
> ones? What if a feature gets a last minute revert in the kernel and it's
> in libbpf's ABI?

You mean when kernel gets new feature, then libbpf gets new feature, then
libbpf is released, but then kernel feature is reverted? Obviously we should
avoid making a libbpf release that relies on kernel features that didn't reach
the mainline. Yet there could be plenty of reasons why making libbpf release in
the middle of kernel development cycle makes perfect sense.

Also reaching Linus's tree in rc1 is also not a guarantee of non-revert. Yet we
release libbpf around rc1 because everyone expects bug-fixes after rc1. So it's
an exception that solidifies the rule.

> > libbpf has to run on all kernels. Newer and older. How do you support
> > that if libbpf is tied with the kernel?
> 
> Say I have built N kernels UM or for a VM, and we have some test
> suite: I pull libbpf, build it, run its tests. The only difference
> between in tree and out of tree is that "pull libbpf" means pulling
> smaller or larger repo. Doesn't matter that match, it's a low --depth
> local clone.

The expected CI is:
1. pull-req proposed.
2. CI picks it up, builds, run tests.
3. humans see results and land or reject pull-req.
Now try to think through how CI on top of full kernel tree will
be able to pick just the right commits to start build/test cycle.
Is it going to cherry-pick from patchworks? That would be awesome.
Yet intel 0bot results show that it's easier said than done.
I'm not saying it's not possible. Just complex.
If you have cycles to integrate *-next into kernelci.org, please go ahead.


  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02 13:18 Jiri Olsa
2019-12-02 13:18 ` [PATCH 1/6] perf tools: Allow to specify libbpf install directory Jiri Olsa
2019-12-02 13:18 ` [PATCH 2/6] bpftool: Allow to link libbpf dynamically Jiri Olsa
2019-12-02 13:18 ` [PATCH 3/6] bpftool: Rename BPF_DIR Makefile variable to LIBBPF_SRC_DIR Jiri Olsa
2019-12-02 13:18 ` [PATCH 4/6] bpftool: Rename LIBBPF_OUTPUT Makefile variable to LIBBPF_BUILD_OUTPUT Jiri Olsa
2019-12-02 13:18 ` [PATCH 5/6] bpftool: Rename LIBBPF_PATH Makefile variable to LIBBPF_BUILD_PATH Jiri Olsa
2019-12-02 13:18 ` [PATCH 6/6] selftests, bpftool: Add build test for libbpf dynamic linking Jiri Olsa
2019-12-02 15:38   ` Quentin Monnet
2019-12-02 19:41 ` [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically Andrii Nakryiko
2019-12-02 21:15   ` Toke Høiland-Jørgensen
2019-12-04  5:52     ` Alexei Starovoitov
2019-12-04  9:01       ` Jiri Olsa
2019-12-04 10:57       ` Toke Høiland-Jørgensen
2019-12-04 17:39         ` Alexei Starovoitov
2019-12-04 18:27           ` Daniel Borkmann
2019-12-04 20:22             ` Toke Høiland-Jørgensen
2019-12-04 21:16       ` Andrii Nakryiko
2019-12-04 21:54         ` Jakub Kicinski
2019-12-04 23:39           ` Alexei Starovoitov
2019-12-05  0:23             ` Jakub Kicinski
2019-12-05  0:29               ` David Miller
2019-12-05  1:25                 ` Alexei Starovoitov
2019-12-05  1:09               ` Alexei Starovoitov
2019-12-05  2:10                 ` Jakub Kicinski
2019-12-05  3:17                   ` Alexei Starovoitov [this message]
2019-12-05  4:26                     ` Jakub Kicinski
2019-12-05  6:44                       ` Alexei Starovoitov
2019-12-05  8:35             ` Jesper Dangaard Brouer
2019-12-05 12:09               ` Michal Rostecki

Reply instructions:

You may reply publically 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=20191205031718.ax46kfv55zauuopt@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=quentin.monnet@netronome.com \
    --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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git