Skip to content

Commit cdd0b42

Browse files
committed
bpftool: Update versioning scheme, align on libbpf's version number
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 <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
1 parent bee3394 commit cdd0b42

File tree

2 files changed

+23
-4
lines changed

2 files changed

+23
-4
lines changed

src/Makefile

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -37,10 +37,6 @@ LIBBPF_BOOTSTRAP := $(LIBBPF_BOOTSTRAP_OUTPUT)libbpf.a
3737
LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h)
3838
LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h)
3939

40-
ifeq ($(BPFTOOL_VERSION),)
41-
BPFTOOL_VERSION := 5.16.0+dc37dc617fab
42-
endif
43-
4440
$(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR):
4541
$(QUIET_MKDIR)mkdir -p $@
4642

@@ -81,7 +77,9 @@ CFLAGS += -DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ \
8177
-I$(srctree)/src/kernel/bpf/ \
8278
-I$(srctree)/include \
8379
-I$(srctree)/include/uapi
80+
ifneq ($(BPFTOOL_VERSION),)
8481
CFLAGS += -DBPFTOOL_VERSION='"$(BPFTOOL_VERSION)"'
82+
endif
8583
ifneq ($(EXTRA_CFLAGS),)
8684
CFLAGS += $(EXTRA_CFLAGS)
8785
endif

src/main.c

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -71,6 +71,17 @@ static int do_help(int argc, char **argv)
7171
return 0;
7272
}
7373

74+
#ifndef BPFTOOL_VERSION
75+
/* bpftool's major and minor version numbers are aligned on libbpf's. There is
76+
* an offset of 6 for the version number, because bpftool's version was higher
77+
* than libbpf's when we adopted this scheme. The patch number remains at 0
78+
* for now. Set BPFTOOL_VERSION to override.
79+
*/
80+
#define BPFTOOL_MAJOR_VERSION (LIBBPF_MAJOR_VERSION + 6)
81+
#define BPFTOOL_MINOR_VERSION LIBBPF_MINOR_VERSION
82+
#define BPFTOOL_PATCH_VERSION 0
83+
#endif
84+
7485
static int do_version(int argc, char **argv)
7586
{
7687
#ifdef HAVE_LIBBFD_SUPPORT
@@ -88,7 +99,12 @@ static int do_version(int argc, char **argv)
8899
jsonw_start_object(json_wtr); /* root object */
89100

90101
jsonw_name(json_wtr, "version");
102+
#ifdef BPFTOOL_VERSION
91103
jsonw_printf(json_wtr, "\"%s\"", BPFTOOL_VERSION);
104+
#else
105+
jsonw_printf(json_wtr, "\"%d.%d.%d\"", BPFTOOL_MAJOR_VERSION,
106+
BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION);
107+
#endif
92108
jsonw_name(json_wtr, "libbpf_version");
93109
jsonw_printf(json_wtr, "\"%d.%d\"",
94110
libbpf_major_version(), libbpf_minor_version());
@@ -104,7 +120,12 @@ static int do_version(int argc, char **argv)
104120
} else {
105121
unsigned int nb_features = 0;
106122

123+
#ifdef BPFTOOL_VERSION
107124
printf("%s v%s\n", bin_name, BPFTOOL_VERSION);
125+
#else
126+
printf("%s v%d.%d.%d\n", bin_name, BPFTOOL_MAJOR_VERSION,
127+
BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION);
128+
#endif
108129
printf("using libbpf %s\n", libbpf_version_string());
109130
printf("features:");
110131
if (has_libbfd) {

0 commit comments

Comments
 (0)