Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp17965021ybl; Thu, 2 Jan 2020 15:47:33 -0800 (PST) X-Google-Smtp-Source: APXvYqxWPR9gpTcjrGqy/NOEas4lIpZRkGVXda5C7qDHt92mA1xKiEAAT4DHYQ/zf7EWziuCdisj X-Received: by 2002:a05:6830:184:: with SMTP id q4mr78231194ota.232.1578008853579; Thu, 02 Jan 2020 15:47:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578008853; cv=none; d=google.com; s=arc-20160816; b=ymmreN+3eHqm6p0mvhQg5Br9OjN3vQBZuoHnMpO8uQAzqjp7PvCFaychIV9z293bUw BX3F6GCJnKF3EnpF+7BdhY9ynkCxBcq+thWhGK4I/lXwQOs7QOdSdB4l84f8QRJ3+s7U /JBPHKv5s/AzK0nCaKfPu930snaLVq8ExuszHZKl0K4+dINJIgGXdMtZ9nbMt6CwzGOC FsIvaBNKHBQwrM9EnqWaX6SpKvJxao3/q0ayOhxOyXG6yPZMLVHtTja6+pDkmZYKqAdm PkhGZUGnLqXNAJGErsKeBGibMHlJZL38ZE/qq03AZ5+9f1o4+U7VvLBAh3CirKkCr5V5 lUwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=eWvceFNhOdUSqlFNEAJNc7V+Rm78ZWWWRF2a4SxYZ6g=; b=GxyLwvkpEUnAw0RR7MmcWrozJBaHEUuQyuEr3ArLsqldCNoBMRCo9hrQ6R7aBnRKC9 i4YGjWDcOWTtQlYFP6URMK3+DjCc+Ea7CTBZQV3n09ZRZ+rT3ORbs79YVnxSxuSp0b53 Pw761v75TeRNU3714iSnWZcLtA/biWNv2A3FgcJEKrykf1/zYMAxk9gdZjS47hBkYMgJ 5q+DfTb/0ZVj1qDeFg2wnTtz4YWF3dKCHDJm3OGiiDCdHmkVGFbEEjTcdSSON4eXqNjq aA5B7GiSgjDKLwJP1Vk84X2LXzsD0VxJO0aOg2LgbqjyWxoVZ54CpUUDliyEFMNQX1wx y9sQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l14si27145532oii.37.2020.01.02.15.47.20; Thu, 02 Jan 2020 15:47:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726640AbgABXqk (ORCPT + 99 others); Thu, 2 Jan 2020 18:46:40 -0500 Received: from mail.kernel.org ([198.145.29.99]:40002 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725872AbgABXqk (ORCPT ); Thu, 2 Jan 2020 18:46:40 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 719322085B; Thu, 2 Jan 2020 23:46:38 +0000 (UTC) Date: Thu, 2 Jan 2020 18:46:36 -0500 From: Steven Rostedt To: Arnaldo Carvalho de Melo Cc: Sudip Mukherjee , Ingo Molnar , Jiri Olsa , Namhyung Kim , Masami Hiramatsu , Linux Trace Devel , LKML , Linus Torvalds , Andrii Nakryiko , Andrey Ignatov , Alexei Starovoitov Subject: Re: [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source? Message-ID: <20200102184636.08375a14@gandalf.local.home> In-Reply-To: <20200102184252.GA8047@kernel.org> References: <20200102122004.216c85da@gandalf.local.home> <20200102184252.GA8047@kernel.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Added the BPF folks ] On Thu, 2 Jan 2020 15:42:52 -0300 Arnaldo Carvalho de Melo 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