From patchwork Thu Feb 10 10:42:36 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12741701 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D05C8C433F5 for ; Thu, 10 Feb 2022 10:42:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239963AbiBJKmq (ORCPT ); Thu, 10 Feb 2022 05:42:46 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:53398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239968AbiBJKmq (ORCPT ); Thu, 10 Feb 2022 05:42:46 -0500 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F0A1FD5 for ; Thu, 10 Feb 2022 02:42:47 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id p24so14255376ejo.1 for ; Thu, 10 Feb 2022 02:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8MCTtOQQV5S6DRMIgEdzgH7o7Z0XnR5RLccuHTb4Jd8=; b=gWyubEMGWUUvIAC7z68ajkZ6Xihr4AsIHu6xju9v4oYuVJCsJKCXyekm8KsXH3fvNq UFymnJUcPSWtm1JiIRi1zAMKehNt34R40m9zWyx3KdLe6E7bIIEjOTAG3OxMwTKTS/rn zdHiUXyEDvysswJIC932CQFn7HGx9rRJj/DuzYY1ElPGv4ZS+8hpKBnpMIUxsL+goFcU ryWkYPbN8PahHCrgb6RLL3cHsvIf+0Q8Q0jX1mSsiXHWKwG1/Nb0nToSiuCMBla/dxgL O1bJd+no8NIObLgL8OYJhtJFSbBTz9EMa3FBUfhlpOLWgOJhNIFZsAqZ8/BRSEPSWlrV jFYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8MCTtOQQV5S6DRMIgEdzgH7o7Z0XnR5RLccuHTb4Jd8=; b=xHRgJVnU+hVEnZBk8IWnE95ZXCk1YQY1Rhmiv+CfeCcEducVWAPs5FOUe/J9HeFPqd 81bpDczyDGdHDQnORX7De91T834WiR/ITmhwYaatjr7Qh+AtM4YMF7kJhTNvSaOWhzcT CraA4Y5C8cERC6NapPMk74RXEozNF1QgAQTccBGqSCK27+v9LZa16g7N/8drU8Bz4iKW tsRgPdgVADEXJtq7f5q2jvhcxVIBUbEh87Kc7vALggHgbuMZVPzof/0V5YipGbSYpjbz zP6LZd6e7UT/tJieOiiMOqNRXg24T9jatVPZ/zhLC1zjdkw//TtFrVp2HN0j9H/kMAPo Ddug== X-Gm-Message-State: AOAM531wgZvYCDHyWGPn8L4w3PfjV8UQUnWXi0TEPPrIkddCAQmFVgL/ l1/H1vLpB+XCbODXrgltHF/43dSnAP5R4A== X-Google-Smtp-Source: ABdhPJxPkrM+QC2tTR24vJqSQD+T2vvto+GAgPJ+sx8ODa60OYdYBNOTX2GrDV9HxKgdP49YLrI6QQ== X-Received: by 2002:a17:906:149a:: with SMTP id x26mr5723043ejc.103.1644489766140; Thu, 10 Feb 2022 02:42:46 -0800 (PST) Received: from localhost.localdomain ([149.86.70.238]) by smtp.gmail.com with ESMTPSA id w8sm6111839ejo.18.2022.02.10.02.42.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Feb 2022 02:42:45 -0800 (PST) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Quentin Monnet Subject: [PATCH bpf-next v3 1/2] bpftool: Add libbpf's version number to "bpftool version" output Date: Thu, 10 Feb 2022 10:42:36 +0000 Message-Id: <20220210104237.11649-2-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220210104237.11649-1-quentin@isovalent.com> References: <20220210104237.11649-1-quentin@isovalent.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net To help users check what version of libbpf is being used with bpftool, print the number along with bpftool's own version number. Output: $ ./bpftool version ./bpftool v5.16.0 using libbpf v0.7 features: libbfd, libbpf_strict, skeletons $ ./bpftool version --json --pretty { "version": "5.16.0", "libbpf_version": "0.7", "features": { "libbfd": true, "libbpf_strict": true, "skeletons": true } } Note that libbpf does not expose its patch number. Signed-off-by: Quentin Monnet --- tools/bpf/bpftool/Documentation/common_options.rst | 13 +++++++------ tools/bpf/bpftool/main.c | 4 ++++ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/tools/bpf/bpftool/Documentation/common_options.rst b/tools/bpf/bpftool/Documentation/common_options.rst index 908487b9c2ad..4107a586b68b 100644 --- a/tools/bpf/bpftool/Documentation/common_options.rst +++ b/tools/bpf/bpftool/Documentation/common_options.rst @@ -4,12 +4,13 @@ Print short help message (similar to **bpftool help**). -V, --version - Print version number (similar to **bpftool version**), and optional - features that were included when bpftool was compiled. Optional - features include linking against libbfd to provide the disassembler - for JIT-ted programs (**bpftool prog dump jited**) and usage of BPF - skeletons (some features like **bpftool prog profile** or showing - pids associated to BPF objects may rely on it). + Print bpftool's version number (similar to **bpftool version**), the + number of the libbpf version in use, and optional features that were + included when bpftool was compiled. Optional features include linking + against libbfd to provide the disassembler for JIT-ted programs + (**bpftool prog dump jited**) and usage of BPF skeletons (some + features like **bpftool prog profile** or showing pids associated to + BPF objects may rely on it). -j, --json Generate JSON output. For commands that cannot produce JSON, this diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c index 490f7bd54e4c..0f2f8de514a4 100644 --- a/tools/bpf/bpftool/main.c +++ b/tools/bpf/bpftool/main.c @@ -89,6 +89,9 @@ static int do_version(int argc, char **argv) jsonw_name(json_wtr, "version"); jsonw_printf(json_wtr, "\"%s\"", BPFTOOL_VERSION); + jsonw_name(json_wtr, "libbpf_version"); + jsonw_printf(json_wtr, "\"%d.%d\"", + libbpf_major_version(), libbpf_minor_version()); jsonw_name(json_wtr, "features"); jsonw_start_object(json_wtr); /* features */ @@ -102,6 +105,7 @@ static int do_version(int argc, char **argv) unsigned int nb_features = 0; printf("%s v%s\n", bin_name, BPFTOOL_VERSION); + printf("using libbpf %s\n", libbpf_version_string()); printf("features:"); if (has_libbfd) { printf(" libbfd"); From patchwork Thu Feb 10 10:42:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Quentin Monnet X-Patchwork-Id: 12741702 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2847CC433FE for ; Thu, 10 Feb 2022 10:42:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239965AbiBJKmx (ORCPT ); Thu, 10 Feb 2022 05:42:53 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:53424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239968AbiBJKms (ORCPT ); Thu, 10 Feb 2022 05:42:48 -0500 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E758FE2 for ; Thu, 10 Feb 2022 02:42:49 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id fy20so14211259ejc.0 for ; Thu, 10 Feb 2022 02:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isovalent-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=/DgZsZE/HDfyMIGrsvl2Ss1rzvht97lXiIVbHEcuqC0=; b=ptmdBux/8jgsJr8usd31KrBACc3pglqzbPrHZ4LVeRMOZhONUsa0hGnMi++0JEr4lO jvqr2snZ3/lqi+bkCQ+0xKnMJ8ZvqK0IklWLLDhL5X0TlHuAZeXzcCdFUcVix837yFvs WB+2v/M8j1p4vwZkFQZ329rnYG8DdTgYf+WIkCSrNYHAokxedEDMp0dlc+tpHtDwHyfL WoacZBtNWY/PpHXYQF0lFJXqCPzygy8kaZDWg+QB8JETZNFzGlWtYxcy3NCxnQzblM09 ogAVVAaw6wQwNvlZQbLbkq/336sXCnToqR3TL3ZKAUMdXVQ9vKZGpCNXn/60ndmvXwwJ n1Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/DgZsZE/HDfyMIGrsvl2Ss1rzvht97lXiIVbHEcuqC0=; b=4GvvoCdy47xqq97KjkuMEIGm7FpHrpad9g4kgCoFbsP3VtlGTlAE/kqvwT3lpAjIew Y0VUaebImFhFxFO/ht2+YC7XJ3zM8ca7ZzqBza0XZ6aPrlbOmbvCW9el0RIBcmbsu1+Q +oJNG+gjCjjQvv8K9aeWW9RphXPN7bxfHz1+C0qiNBBeiBA0AxFqz5syVyGboV9B0dMI AE1BRkyhSxtln5nMaxBCcmkRx5yXiH7YyQ34Yv8aFTzy0Omi5U+VBqKwaqorkrh942OO ySQR+1hNJDw3fLJEzTe+e/cWViPJbabOgb05hQNcy2r/DZiJaIF/3TIC4df+0v3eVeaK pd1A== X-Gm-Message-State: AOAM531nk1MYVrA/GVWtQGhyiGamdWoNL/mo1D5G5CauM4XhRs0+2sfZ 5DCoo5YKUBD6y4xxVZWYgRy1yA== X-Google-Smtp-Source: ABdhPJyLSF2kQZRNV+ztZliqS7rlSkanslbMnZSV/3Xn4n/nnEKVI9v/qMU4QbLSNi8ZvL5B7u2sOg== X-Received: by 2002:a17:906:8396:: with SMTP id p22mr5784036ejx.153.1644489767400; Thu, 10 Feb 2022 02:42:47 -0800 (PST) Received: from localhost.localdomain ([149.86.70.238]) by smtp.gmail.com with ESMTPSA id w8sm6111839ejo.18.2022.02.10.02.42.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Feb 2022 02:42:46 -0800 (PST) From: Quentin Monnet To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Quentin Monnet Subject: [PATCH bpf-next v3 2/2] bpftool: Update versioning scheme, align on libbpf's version number Date: Thu, 10 Feb 2022 10:42:37 +0000 Message-Id: <20220210104237.11649-3-quentin@isovalent.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220210104237.11649-1-quentin@isovalent.com> References: <20220210104237.11649-1-quentin@isovalent.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net Since the notion of versions was introduced for bpftool, it has been following the version number of the kernel (using the version number corresponding to the tree in which bpftool's sources are located). The rationale was that bpftool's features are loosely tied to BPF features in the kernel, and that we could defer versioning to the kernel repository itself. But this versioning scheme is confusing today, because a bpftool binary should be able to work with both older and newer kernels, even if some of its recent features won't be available on older systems. Furthermore, if bpftool is ported to other systems in the future, keeping a Linux-based version number is not a good option. Looking at other options, we could either have a totally independent scheme for bpftool, or we could align it on libbpf's version number (with an offset on the major version number, to avoid going backwards). The latter comes with a few drawbacks: - We may want bpftool releases in-between two libbpf versions. We can always append pre-release numbers to distinguish versions, although those won't look as "official" as something with a proper release number. But at the same time, having bpftool with version numbers that look "official" hasn't really been an issue so far. - If no new feature lands in bpftool for some time, we may move from e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different versions which are in fact the same. - Following libbpf's versioning scheme sounds better than kernel's, but ultimately it doesn't make too much sense either, because even though bpftool uses the lib a lot, its behaviour is not that much conditioned by the internal evolution of the library (or by new APIs that it may not use). Having an independent versioning scheme solves the above, but at the cost of heavier maintenance. Developers will likely forget to increase the numbers when adding features or bug fixes, and we would take the risk of having to send occasional "catch-up" patches just to update the version number. Based on these considerations, this patch aligns bpftool's version number on libbpf's. This is not a perfect solution, but 1) it's certainly an improvement over the current scheme, 2) the issues raised above are all minor at the moment, and 3) we can still move to an independent scheme in the future if we realise we need it. Given that libbpf is currently at version 0.7.0, and bpftool, before this patch, was at 5.16, we use an offset of 6 for the major version, bumping bpftool to 6.7.0. Libbpf does not export its patch number; leave bpftool's patch number at 0 for now. It remains possible to manually override the version number by setting BPFTOOL_VERSION when calling make. Signed-off-by: Quentin Monnet --- tools/bpf/bpftool/Makefile | 6 ++---- tools/bpf/bpftool/main.c | 21 +++++++++++++++++++++ 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile index 83369f55df61..94b2c2f4ad43 100644 --- a/tools/bpf/bpftool/Makefile +++ b/tools/bpf/bpftool/Makefile @@ -39,10 +39,6 @@ LIBBPF_BOOTSTRAP := $(LIBBPF_BOOTSTRAP_OUTPUT)libbpf.a LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h) LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h) -ifeq ($(BPFTOOL_VERSION),) -BPFTOOL_VERSION := $(shell make -rR --no-print-directory -sC ../../.. kernelversion) -endif - $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR): $(QUIET_MKDIR)mkdir -p $@ @@ -83,7 +79,9 @@ CFLAGS += -DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ \ -I$(srctree)/kernel/bpf/ \ -I$(srctree)/tools/include \ -I$(srctree)/tools/include/uapi +ifneq ($(BPFTOOL_VERSION),) CFLAGS += -DBPFTOOL_VERSION='"$(BPFTOOL_VERSION)"' +endif ifneq ($(EXTRA_CFLAGS),) CFLAGS += $(EXTRA_CFLAGS) endif diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c index 0f2f8de514a4..e81227761f5d 100644 --- a/tools/bpf/bpftool/main.c +++ b/tools/bpf/bpftool/main.c @@ -71,6 +71,17 @@ static int do_help(int argc, char **argv) return 0; } +#ifndef BPFTOOL_VERSION +/* bpftool's major and minor version numbers are aligned on libbpf's. There is + * an offset of 6 for the version number, because bpftool's version was higher + * than libbpf's when we adopted this scheme. The patch number remains at 0 + * for now. Set BPFTOOL_VERSION to override. + */ +#define BPFTOOL_MAJOR_VERSION (LIBBPF_MAJOR_VERSION + 6) +#define BPFTOOL_MINOR_VERSION LIBBPF_MINOR_VERSION +#define BPFTOOL_PATCH_VERSION 0 +#endif + static int do_version(int argc, char **argv) { #ifdef HAVE_LIBBFD_SUPPORT @@ -88,7 +99,12 @@ static int do_version(int argc, char **argv) jsonw_start_object(json_wtr); /* root object */ jsonw_name(json_wtr, "version"); +#ifdef BPFTOOL_VERSION jsonw_printf(json_wtr, "\"%s\"", BPFTOOL_VERSION); +#else + jsonw_printf(json_wtr, "\"%d.%d.%d\"", BPFTOOL_MAJOR_VERSION, + BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION); +#endif jsonw_name(json_wtr, "libbpf_version"); jsonw_printf(json_wtr, "\"%d.%d\"", libbpf_major_version(), libbpf_minor_version()); @@ -104,7 +120,12 @@ static int do_version(int argc, char **argv) } else { unsigned int nb_features = 0; +#ifdef BPFTOOL_VERSION printf("%s v%s\n", bin_name, BPFTOOL_VERSION); +#else + printf("%s v%d.%d.%d\n", bin_name, BPFTOOL_MAJOR_VERSION, + BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION); +#endif printf("using libbpf %s\n", libbpf_version_string()); printf("features:"); if (has_libbfd) {