linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Linux Trace Devel <linux-trace-devel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrii Nakryiko <andriin@fb.com>, Andrey Ignatov <rdna@fb.com>,
	Alexei Starovoitov <ast@kernel.org>
Subject: Re: [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source?
Date: Thu, 2 Jan 2020 18:46:36 -0500	[thread overview]
Message-ID: <20200102184636.08375a14@gandalf.local.home> (raw)
In-Reply-To: <20200102184252.GA8047@kernel.org>


[ Added the BPF folks ]

On Thu, 2 Jan 2020 15:42:52 -0300
Arnaldo Carvalho de Melo <arnaldo.melo@gmail.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

  reply	other threads:[~2020-01-02 23:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02 17:20 [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source? Steven Rostedt
2020-01-02 18:42 ` Arnaldo Carvalho de Melo
2020-01-02 23:46   ` Steven Rostedt [this message]
2020-01-02 22:43 ` Sudip Mukherjee
2020-01-03 23:19   ` Steven Rostedt
2020-01-07 13:15     ` Namhyung Kim
2020-01-02 23:49 ` Jiri Olsa
2020-01-02 23:58   ` Steven Rostedt
2020-01-03  0:09     ` Sudip Mukherjee
2020-01-03 13:36     ` Jiri Olsa
2020-01-03 18:29       ` Sudip Mukherjee
2020-01-03 23:16       ` Steven Rostedt
2020-01-06 15:19         ` Jiri Olsa
2020-01-06 16:26           ` Arnaldo Carvalho de Melo
2020-01-06 16:36             ` Steven Rostedt
2020-01-06 19:47               ` Arnaldo Carvalho de Melo
2020-01-06 20:14                 ` Konstantin Ryabitsev
2020-01-06 22:00                   ` Arnaldo Carvalho de Melo
2020-01-06 20:47               ` [kernel.org users] " Jason Gunthorpe
2020-01-06 20:52                 ` Steven Rostedt
2020-01-07 17:44                   ` Jason Gunthorpe
2020-01-06 18:22           ` Konstantin Ryabitsev
2020-01-03 12:17 ` Masami Hiramatsu
2020-01-03 23:12   ` Steven Rostedt
2020-01-05 13:18     ` Masami Hiramatsu

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=20200102184636.08375a14@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=andriin@fb.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=ast@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=rdna@fb.com \
    --cc=sudipm.mukherjee@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).