linux-kernel - Re: [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200102184636.08375a14@gandalf.local.home>
Date:   Thu, 2 Jan 2020 18:46:36 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc:     Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Linux Trace Devel <linux-trace-devel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrii Nakryiko <andriin@...com>, Andrey Ignatov <rdna@...com>,
        Alexei Starovoitov <ast@...nel.org>
Subject: Re: [RFC] tools lib traceevent: How to do library versioning being
 in the Linux kernel source?


[ Added the BPF folks ]

On Thu, 2 Jan 2020 15:42:52 -0300
Arnaldo Carvalho de Melo <arnaldo.melo@...il.com> wrote:

> Em Thu, Jan 02, 2020 at 12:20:04PM -0500, Steven Rostedt escreveu:
> > This is a problem with living in the Linux source tree as tags and
> > branches in Linus's tree are for only the Linux kernel source itself.
> > This may work fine for perf, as it's not a library and there's not  
> 

> 
> libperf adopted the versioning and packaging practices introduced by
> tools/lib/bpf, perhaps you could do the same for tools/lib/traceevent
> and then we would have a standard for these cases?

I don't see libperf in my Debian testing installation, but I did find
libbpf.

> 
> The problem of having libperf, libbpf in distros is already being
> tackled for quite a while, would be interesting to follow what has
> happened in that area as well, Jiri knows more about this, Jiri?

Looking at the libbpf Makefile, it is getting the version from the
libbpf.map file.

What's the standard way for distributions to know when to use the
number? Only from Linux stable trees? That way, we can make fixes to the
library, but still need to remember to update the version number before
the release.

How does libbpf handle the version numbers with bug fixes? Does it get
updated one a kernel release if there are changes?

Obviously, we need to update the major number if the API changes in
anyway that is not compatible for a new application, which includes
adding new functions. Right?

-- Steve