linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Arnaldo Carvalho de Melo <acme@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>
Subject: [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source?
Date: Thu, 2 Jan 2020 12:20:04 -0500	[thread overview]
Message-ID: <20200102122004.216c85da@gandalf.local.home> (raw)

First, I hope everyone had a Happy New Year!

Next, Sudip has been working to get the libtraceevent library into
Debian. As this has been happening, I've been working at how to get all
the projects that use this, to use the library installed on the system
if it does exist. I'm hoping that once it's in Debian, the other
distros will follow suit.

Currently, the home of libtraceevent lives in the Linux kernel source
tree under tools/lib/traceevent. This was because perf uses it to parse
the events, and it seemed logical (at the time) to use this location as
the main source tree for the distributions.

The problem I'm now having is that I'm looking at fixing and updating
some of the code in this library, and since library versioning is
critical for applications that depend on it, we need to have a way to
update the versions, and this does not correspond with the Linux
versions.

For example, we currently have:

 libtraceevent.so.1.1.0

If I make some bug fixes, I probably want to change it to:

 libtraceevent.so.1.1.1 or libtraceevent.so.1.2.0

But if I change the API, which I plan on doing soon, I would probably
need to update the major version.

 libtraceevent.so.2.0.0

The thing is, we shouldn't be making these changes for every update
that we send to the main kernel. I would like to have a minimum of tags
to state what the version should be, and perhaps even branches for
working on a development version.

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
tools depending on the version of it. But it is a problem when it comes
to shared libraries.

Should we move libtraceevent into a stand alone git repo (on
kernel.org), that can have tags and branches specifically for it? We
can keep a copy in the Linux source tree for perf to use till it
becomes something that is reliably in all distributions. It's not like
perf doesn't depend on other libraries today anyway.

Thoughts or suggestions?

Thanks!

-- Steve

             reply	other threads:[~2020-01-02 17:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02 17:20 Steven Rostedt [this message]
2020-01-02 18:42 ` [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source? Arnaldo Carvalho de Melo
2020-01-02 23:46   ` Steven Rostedt
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=20200102122004.216c85da@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=acme@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=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).