Bug#948041: impossible to update libbpf without updating the kernel
On Sat, Jan 18, 2020 at 7:48 AM Bastian Blank <bblank@thinkmo.de> wrote:
>
> On Wed, Jan 15, 2020 at 12:50:16PM +0000, Sudip Mukherjee wrote:
> > On Wed, Jan 15, 2020 at 06:12:05AM +0000, Jonathan Nieder wrote:
> > > I agree --- if upstream development were happening in
> > > https://github.com/libbpf/libbpf then this would be a no-brainer. It
> > > appears to instead be a mirror of the source that's in the kernel
> > > repo, though.
> > That will be difficult as all of them are dependent on the ftrace hooks
> > that are in the kernel.
>
> What will be difficult?
>
> > > > Why should we switch from kernel sources to GH is a frequently asked
> > > > question so the reason was explained in libbpf README [1].
>
> Let's go through it one by one.
>
> "Consistent versioning across distributions."
>
> Maybe, but the kernel is also versioned consistently.
Libbpf releases are only loosely synchronized with kernel releases,
and it's only due to current convention we established within
community. There is nothing preventing multiple releases of libbpf
between two releases of kernel. So having Linux distributions use
Github's release tags ensures that all of them are building from
exactly the same source code version.
> "No ties to any specific kernel, transparent handling of older kernels."
>
> What? Either they are upstream for it or patch the source. But this
> point means it can't be a direct mirror. So what is it?
It is mostly a direct mirror, with some extra Github-specific stuff
beside (like Travis CI testing, etc). All the libbpf source code fixes
do go through bpf-next tree, though.
But the point here was that libbpf itself is not built with any
particular kernel version in mind. It is by design possible to use the
very latest libbpf against a pretty old kernel version and this will
work: libbpf will degrade some of the features (e.g, BTF type info
associations), but everything will keep working otherwise (unless user
requests feature that requires latest kernel version, of course: in
that case BPF program will fail to load and libbpf will return
corresponding error code).
>
> "Continuous integration testing via TravisCI."
> "Static code analysis via LGTM and Coverity."
>
> Both are not restricted to this repo.
Not sure what you mean by this. We can't have Travis CI integration w/
bpf-next source tree. But we can and we have it for Github mirror,
which runs tests and static analysis for every sync pull request. We
already have and are enhancing at the moment our testing set up to
test multiple kernels in multiple environments.
>
> > > If I'm reading that correctly, the intent appears to be that it would
> > > allow faster libbpf upgrades.
> > Yes, one of my intent. Faster and independent.
>
> And how does it do that, without being upstream of the source?
>
> Sorry, but I intend to end this discussion here.
>
> Bastian
>
> --
> It would be illogical to assume that all conditions remain stable.
> -- Spock, "The Enterprise Incident", stardate 5027.3
>
> --
> To unsubscribe, send mail to 948041-unsubscribe@bugs.debian.org.
Reply to: