Re: Packaging bpftool and libbpf: GitHub or kernel?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 20, 2023 at 02:39:17PM -0700, Andrii Nakryiko wrote:
> On Thu, Apr 20, 2023 at 7:46 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
> > [snip]
> > Right, well, you don't *have* to be cooperative with the wider
> > ecosystem, of course. Just as packagers don't have to follow your
> > recommendations if they have good reasons not to. I believe we've had
> > this discussion before, and I don't think we're going to agree this time
> > around either, so let's not waste any more virtual ink on rehashing it :)
> 
> Exactly, so I'm not sure why we are even having this conversation all
> over again. I agree on not wasting virtual ink anymore. I'm not
> forcing anyone to follow my advice, I expect others to not force me to
> follow theirs.

Thanks for still going through the reasoning.

I don't have anything to add to the discussion, so instead here's an attempt
to summarize the thread thus far, reading between the lines here and there
to keep it terse but complete; feel free to point out where I misunderstood.


# Packaging bpftool and libbpf

- bpftool and libbpf version should be kept in sync
  - interdependency is by design
  - bpftool uses private functionality of libbpf
  - bpftool generated file is tie to specific libbpf (?)

- the GitHub mirror is the recommended source 

- benefits of using the GitHub mirror includes
  - ease of upgrade
  - maintainer crafted changelog

- downsides of using the GitHub mirror has to do with kernel backporting

- git submodule requires extra work for distros to package
  - offsetted if the source of submodules are released along

- bpftool releases will (have a file that) includes submodules' source along
  going forward

- bpftool and libbpf both should work on earlier kernel (if not it's a bug)


# Other

- motivations for GitHub mirror
  - ease of distribution, packaging, build
  - CI, to be used as submodule, Window support, etc.

- libbpf interface stability
  - stable API and ABI (within major version)
  - BPF object format is not considered stable

- libbpf is not opinionated in how it's used as a library, either
  - statically or dynamically linked
  - a tagged release or a random commit

- on statically linking libbpf
  - reasoning
    - full control of implementation detail, decouples from distro package
  - against
    - difficulty in applying fixes


Shung-Hsi

> >
> > -Toke
> >



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux