2018-12-12 19:59:25 -08:00
|
|
|
// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
|
|
|
/* Copyright (C) 2017-2018 Netronome Systems, Inc. */
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
#include <ctype.h>
|
|
|
|
#include <errno.h>
|
2017-10-23 09:24:06 -07:00
|
|
|
#include <getopt.h>
|
2017-10-04 20:10:04 -07:00
|
|
|
#include <linux/bpf.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
2020-01-20 14:06:46 +01:00
|
|
|
#include <bpf/bpf.h>
|
2020-11-04 20:34:01 -08:00
|
|
|
#include <bpf/btf.h>
|
bpftool: Switch to libbpf's hashmap for PIDs/names references
In order to show PIDs and names for processes holding references to BPF
programs, maps, links, or BTF objects, bpftool creates hash maps to
store all relevant information. This commit is part of a set that
transitions from the kernel's hash map implementation to the one coming
with libbpf.
The motivation is to make bpftool less dependent of kernel headers, to
ease the path to a potential out-of-tree mirror, like libbpf has.
This is the third and final step of the transition, in which we convert
the hash maps used for storing the information about the processes
holding references to BPF objects (programs, maps, links, BTF), and at
last we drop the inclusion of tools/include/linux/hashtable.h.
Note: Checkpatch complains about the use of __weak declarations, and the
missing empty lines after the bunch of empty function declarations when
compiling without the BPF skeletons (none of these were introduced in
this patch). We want to keep things as they are, and the reports should
be safe to ignore.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com
2021-10-23 21:51:54 +01:00
|
|
|
#include <bpf/hashmap.h>
|
|
|
|
#include <bpf/libbpf.h>
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
#include "main.h"
|
|
|
|
|
2018-03-01 20:20:09 -08:00
|
|
|
#define BATCH_LINE_LEN_MAX 65536
|
|
|
|
#define BATCH_ARG_NB_MAX 4096
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
const char *bin_name;
|
|
|
|
static int last_argc;
|
|
|
|
static char **last_argv;
|
|
|
|
static int (*last_do_help)(int argc, char **argv);
|
2017-10-23 09:24:07 -07:00
|
|
|
json_writer_t *json_wtr;
|
|
|
|
bool pretty_output;
|
|
|
|
bool json_output;
|
2017-11-08 13:55:49 +09:00
|
|
|
bool show_pinned;
|
2018-12-18 10:13:19 +00:00
|
|
|
bool block_mount;
|
2019-05-24 11:36:48 +01:00
|
|
|
bool verifier_logs;
|
2019-10-07 15:56:04 -07:00
|
|
|
bool relaxed_maps;
|
2021-05-13 17:36:19 -07:00
|
|
|
bool use_loader;
|
2020-11-04 20:34:01 -08:00
|
|
|
struct btf *base_btf;
|
bpftool: Switch to libbpf's hashmap for PIDs/names references
In order to show PIDs and names for processes holding references to BPF
programs, maps, links, or BTF objects, bpftool creates hash maps to
store all relevant information. This commit is part of a set that
transitions from the kernel's hash map implementation to the one coming
with libbpf.
The motivation is to make bpftool less dependent of kernel headers, to
ease the path to a potential out-of-tree mirror, like libbpf has.
This is the third and final step of the transition, in which we convert
the hash maps used for storing the information about the processes
holding references to BPF objects (programs, maps, links, BTF), and at
last we drop the inclusion of tools/include/linux/hashtable.h.
Note: Checkpatch complains about the use of __weak declarations, and the
missing empty lines after the bunch of empty function declarations when
compiling without the BPF skeletons (none of these were introduced in
this patch). We want to keep things as they are, and the reports should
be safe to ignore.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211023205154.6710-6-quentin@isovalent.com
2021-10-23 21:51:54 +01:00
|
|
|
struct hashmap *refs_table;
|
2017-10-04 20:10:04 -07:00
|
|
|
|
2017-11-28 17:44:29 -08:00
|
|
|
static void __noreturn clean_and_exit(int i)
|
|
|
|
{
|
|
|
|
if (json_output)
|
|
|
|
jsonw_destroy(&json_wtr);
|
|
|
|
|
|
|
|
exit(i);
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
void usage(void)
|
|
|
|
{
|
|
|
|
last_do_help(last_argc - 1, last_argv + 1);
|
|
|
|
|
2017-11-28 17:44:29 -08:00
|
|
|
clean_and_exit(-1);
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int do_help(int argc, char **argv)
|
|
|
|
{
|
2017-10-23 09:24:14 -07:00
|
|
|
if (json_output) {
|
|
|
|
jsonw_null(json_wtr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
fprintf(stderr,
|
2017-10-23 09:24:16 -07:00
|
|
|
"Usage: %s [OPTIONS] OBJECT { COMMAND | help }\n"
|
2017-10-04 20:10:04 -07:00
|
|
|
" %s batch file FILE\n"
|
2017-10-19 15:46:26 -07:00
|
|
|
" %s version\n"
|
2017-10-04 20:10:04 -07:00
|
|
|
"\n"
|
2020-05-09 10:59:20 -07:00
|
|
|
" OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }\n"
|
2021-07-30 22:54:32 +01:00
|
|
|
" " HELP_SPEC_OPTIONS " |\n"
|
|
|
|
" {-V|--version} }\n"
|
2017-10-23 09:24:16 -07:00
|
|
|
"",
|
2017-10-19 15:46:26 -07:00
|
|
|
bin_name, bin_name, bin_name);
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-10-20 11:03:32 +01:00
|
|
|
static int do_batch(int argc, char **argv);
|
|
|
|
static int do_version(int argc, char **argv);
|
|
|
|
|
|
|
|
static const struct cmd commands[] = {
|
|
|
|
{ "help", do_help },
|
|
|
|
{ "batch", do_batch },
|
|
|
|
{ "prog", do_prog },
|
|
|
|
{ "map", do_map },
|
|
|
|
{ "link", do_link },
|
|
|
|
{ "cgroup", do_cgroup },
|
|
|
|
{ "perf", do_perf },
|
|
|
|
{ "net", do_net },
|
|
|
|
{ "feature", do_feature },
|
|
|
|
{ "btf", do_btf },
|
|
|
|
{ "gen", do_gen },
|
|
|
|
{ "struct_ops", do_struct_ops },
|
|
|
|
{ "iter", do_iter },
|
|
|
|
{ "version", do_version },
|
|
|
|
{ 0 }
|
|
|
|
};
|
|
|
|
|
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 <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#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
|
|
|
|
|
2022-10-20 11:03:32 +01:00
|
|
|
static void
|
|
|
|
print_feature(const char *feature, bool state, unsigned int *nb_features)
|
|
|
|
{
|
|
|
|
if (state) {
|
|
|
|
printf("%s %s", *nb_features ? "," : "", feature);
|
|
|
|
*nb_features = *nb_features + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-19 15:46:26 -07:00
|
|
|
static int do_version(int argc, char **argv)
|
|
|
|
{
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
#ifdef HAVE_LIBBFD_SUPPORT
|
|
|
|
const bool has_libbfd = true;
|
|
|
|
#else
|
|
|
|
const bool has_libbfd = false;
|
|
|
|
#endif
|
2022-10-25 16:03:29 +01:00
|
|
|
#ifdef HAVE_LLVM_SUPPORT
|
|
|
|
const bool has_llvm = true;
|
|
|
|
#else
|
|
|
|
const bool has_llvm = false;
|
|
|
|
#endif
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
#ifdef BPFTOOL_WITHOUT_SKELETONS
|
|
|
|
const bool has_skeletons = false;
|
|
|
|
#else
|
|
|
|
const bool has_skeletons = true;
|
|
|
|
#endif
|
2022-10-20 11:03:32 +01:00
|
|
|
bool bootstrap = false;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; commands[i].cmd; i++) {
|
|
|
|
if (!strcmp(commands[i].cmd, "prog")) {
|
|
|
|
/* Assume we run a bootstrap version if "bpftool prog"
|
|
|
|
* is not available.
|
|
|
|
*/
|
|
|
|
bootstrap = !commands[i].func;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
|
2017-10-23 09:24:14 -07:00
|
|
|
if (json_output) {
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
jsonw_start_object(json_wtr); /* root object */
|
|
|
|
|
2017-10-23 09:24:14 -07:00
|
|
|
jsonw_name(json_wtr, "version");
|
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 <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#ifdef BPFTOOL_VERSION
|
2017-12-27 19:16:28 +00:00
|
|
|
jsonw_printf(json_wtr, "\"%s\"", BPFTOOL_VERSION);
|
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 <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#else
|
|
|
|
jsonw_printf(json_wtr, "\"%d.%d.%d\"", BPFTOOL_MAJOR_VERSION,
|
|
|
|
BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION);
|
|
|
|
#endif
|
2022-02-10 10:42:36 +00:00
|
|
|
jsonw_name(json_wtr, "libbpf_version");
|
|
|
|
jsonw_printf(json_wtr, "\"%d.%d\"",
|
|
|
|
libbpf_major_version(), libbpf_minor_version());
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
|
|
|
|
jsonw_name(json_wtr, "features");
|
|
|
|
jsonw_start_object(json_wtr); /* features */
|
|
|
|
jsonw_bool_field(json_wtr, "libbfd", has_libbfd);
|
2022-10-25 16:03:29 +01:00
|
|
|
jsonw_bool_field(json_wtr, "llvm", has_llvm);
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
jsonw_bool_field(json_wtr, "skeletons", has_skeletons);
|
2022-10-20 11:03:32 +01:00
|
|
|
jsonw_bool_field(json_wtr, "bootstrap", bootstrap);
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
jsonw_end_object(json_wtr); /* features */
|
|
|
|
|
|
|
|
jsonw_end_object(json_wtr); /* root object */
|
2017-10-23 09:24:14 -07:00
|
|
|
} else {
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
unsigned int nb_features = 0;
|
|
|
|
|
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 <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#ifdef BPFTOOL_VERSION
|
2017-12-27 19:16:28 +00:00
|
|
|
printf("%s v%s\n", bin_name, BPFTOOL_VERSION);
|
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 <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
2022-02-10 10:42:37 +00:00
|
|
|
#else
|
|
|
|
printf("%s v%d.%d.%d\n", bin_name, BPFTOOL_MAJOR_VERSION,
|
|
|
|
BPFTOOL_MINOR_VERSION, BPFTOOL_PATCH_VERSION);
|
|
|
|
#endif
|
2022-02-10 10:42:36 +00:00
|
|
|
printf("using libbpf %s\n", libbpf_version_string());
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
printf("features:");
|
2022-10-20 11:03:32 +01:00
|
|
|
print_feature("libbfd", has_libbfd, &nb_features);
|
2022-10-25 16:03:29 +01:00
|
|
|
print_feature("llvm", has_llvm, &nb_features);
|
2022-10-20 11:03:32 +01:00
|
|
|
print_feature("skeletons", has_skeletons, &nb_features);
|
|
|
|
print_feature("bootstrap", bootstrap, &nb_features);
|
tools: bpftool: Print optional built-in features along with version
Bpftool has a number of features that can be included or left aside
during compilation. This includes:
- Support for libbfd, providing the disassembler for JIT-compiled
programs.
- Support for BPF skeletons, used for profiling programs or iterating on
the PIDs of processes associated with BPF objects.
In order to make it easy for users to understand what features were
compiled for a given bpftool binary, print the status of the two
features above when showing the version number for bpftool ("bpftool -V"
or "bpftool version"). Document this in the main manual page. Example
invocations:
$ bpftool version
./bpftool v5.9.0-rc1
features: libbfd, skeletons
$ bpftool -p version
{
"version": "5.9.0-rc1",
"features": {
"libbfd": true,
"skeletons": true
}
}
Some other parameters are optional at compilation
("DISASM_FOUR_ARGS_SIGNATURE", LIBCAP support) but they do not impact
significantly bpftool's behaviour from a user's point of view, so their
status is not reported.
Available commands and supported program types depend on the version
number, and are therefore not reported either. Note that they are
already available, albeit without JSON, via bpftool's help messages.
v3:
- Use a simple list instead of boolean values for plain output.
v2:
- Fix JSON (object instead or array for the features).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200909162500.17010-2-quentin@isovalent.com
2020-09-09 17:24:58 +01:00
|
|
|
printf("\n");
|
2017-10-23 09:24:14 -07:00
|
|
|
}
|
2017-10-19 15:46:26 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
int cmd_select(const struct cmd *cmds, int argc, char **argv,
|
|
|
|
int (*help)(int argc, char **argv))
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
last_argc = argc;
|
|
|
|
last_argv = argv;
|
|
|
|
last_do_help = help;
|
|
|
|
|
|
|
|
if (argc < 1 && cmds[0].func)
|
|
|
|
return cmds[0].func(argc, argv);
|
|
|
|
|
2020-06-19 16:16:59 -07:00
|
|
|
for (i = 0; cmds[i].cmd; i++) {
|
|
|
|
if (is_prefix(*argv, cmds[i].cmd)) {
|
|
|
|
if (!cmds[i].func) {
|
|
|
|
p_err("command '%s' is not supported in bootstrap mode",
|
|
|
|
cmds[i].cmd);
|
|
|
|
return -1;
|
|
|
|
}
|
2017-10-04 20:10:04 -07:00
|
|
|
return cmds[i].func(argc - 1, argv + 1);
|
2020-06-19 16:16:59 -07:00
|
|
|
}
|
|
|
|
}
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
help(argc - 1, argv + 1);
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool is_prefix(const char *pfx, const char *str)
|
|
|
|
{
|
|
|
|
if (!pfx)
|
|
|
|
return false;
|
|
|
|
if (strlen(str) < strlen(pfx))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !memcmp(str, pfx, strlen(pfx));
|
|
|
|
}
|
|
|
|
|
2019-07-05 18:54:33 +01:00
|
|
|
/* Last argument MUST be NULL pointer */
|
|
|
|
int detect_common_prefix(const char *arg, ...)
|
|
|
|
{
|
|
|
|
unsigned int count = 0;
|
|
|
|
const char *ref;
|
|
|
|
char msg[256];
|
|
|
|
va_list ap;
|
|
|
|
|
|
|
|
snprintf(msg, sizeof(msg), "ambiguous prefix: '%s' could be '", arg);
|
|
|
|
va_start(ap, arg);
|
|
|
|
while ((ref = va_arg(ap, const char *))) {
|
|
|
|
if (!is_prefix(arg, ref))
|
|
|
|
continue;
|
|
|
|
count++;
|
|
|
|
if (count > 1)
|
|
|
|
strncat(msg, "' or '", sizeof(msg) - strlen(msg) - 1);
|
|
|
|
strncat(msg, ref, sizeof(msg) - strlen(msg) - 1);
|
|
|
|
}
|
|
|
|
va_end(ap);
|
|
|
|
strncat(msg, "'", sizeof(msg) - strlen(msg) - 1);
|
|
|
|
|
|
|
|
if (count >= 2) {
|
2019-08-15 15:32:19 +01:00
|
|
|
p_err("%s", msg);
|
2019-07-05 18:54:33 +01:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-10-19 15:46:19 -07:00
|
|
|
void fprint_hex(FILE *f, void *arg, unsigned int n, const char *sep)
|
2017-10-04 20:10:04 -07:00
|
|
|
{
|
|
|
|
unsigned char *data = arg;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for (i = 0; i < n; i++) {
|
|
|
|
const char *pfx = "";
|
|
|
|
|
|
|
|
if (!i)
|
|
|
|
/* nothing */;
|
|
|
|
else if (!(i % 16))
|
2017-10-19 15:46:19 -07:00
|
|
|
fprintf(f, "\n");
|
2017-10-04 20:10:04 -07:00
|
|
|
else if (!(i % 8))
|
2017-10-19 15:46:19 -07:00
|
|
|
fprintf(f, " ");
|
2017-10-04 20:10:04 -07:00
|
|
|
else
|
|
|
|
pfx = sep;
|
|
|
|
|
2017-10-19 15:46:19 -07:00
|
|
|
fprintf(f, "%s%02hhx", i ? pfx : "", data[i]);
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-01 20:20:11 -08:00
|
|
|
/* Split command line into argument vector. */
|
|
|
|
static int make_args(char *line, char *n_argv[], int maxargs, int cmd_nb)
|
|
|
|
{
|
|
|
|
static const char ws[] = " \t\r\n";
|
|
|
|
char *cp = line;
|
|
|
|
int n_argc = 0;
|
|
|
|
|
|
|
|
while (*cp) {
|
|
|
|
/* Skip leading whitespace. */
|
|
|
|
cp += strspn(cp, ws);
|
|
|
|
|
|
|
|
if (*cp == '\0')
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (n_argc >= (maxargs - 1)) {
|
|
|
|
p_err("too many arguments to command %d", cmd_nb);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Word begins with quote. */
|
|
|
|
if (*cp == '\'' || *cp == '"') {
|
|
|
|
char quote = *cp++;
|
|
|
|
|
|
|
|
n_argv[n_argc++] = cp;
|
|
|
|
/* Find ending quote. */
|
|
|
|
cp = strchr(cp, quote);
|
|
|
|
if (!cp) {
|
|
|
|
p_err("unterminated quoted string in command %d",
|
|
|
|
cmd_nb);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
n_argv[n_argc++] = cp;
|
|
|
|
|
|
|
|
/* Find end of word. */
|
|
|
|
cp += strcspn(cp, ws);
|
|
|
|
if (*cp == '\0')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Separate words. */
|
|
|
|
*cp++ = 0;
|
|
|
|
}
|
|
|
|
n_argv[n_argc] = NULL;
|
|
|
|
|
|
|
|
return n_argc;
|
|
|
|
}
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
static int do_batch(int argc, char **argv)
|
|
|
|
{
|
2018-03-01 20:20:09 -08:00
|
|
|
char buf[BATCH_LINE_LEN_MAX], contline[BATCH_LINE_LEN_MAX];
|
|
|
|
char *n_argv[BATCH_ARG_NB_MAX];
|
2017-10-04 20:10:04 -07:00
|
|
|
unsigned int lines = 0;
|
|
|
|
int n_argc;
|
|
|
|
FILE *fp;
|
2018-03-01 20:20:08 -08:00
|
|
|
char *cp;
|
2021-03-13 13:09:18 -08:00
|
|
|
int err = 0;
|
2017-10-23 09:24:12 -07:00
|
|
|
int i;
|
2017-10-04 20:10:04 -07:00
|
|
|
|
|
|
|
if (argc < 2) {
|
2017-10-23 09:24:13 -07:00
|
|
|
p_err("too few parameters for batch");
|
2017-10-04 20:10:04 -07:00
|
|
|
return -1;
|
|
|
|
} else if (argc > 2) {
|
2017-10-23 09:24:13 -07:00
|
|
|
p_err("too many parameters for batch");
|
2017-10-04 20:10:04 -07:00
|
|
|
return -1;
|
2022-11-15 21:00:07 +08:00
|
|
|
} else if (!is_prefix(*argv, "file")) {
|
|
|
|
p_err("expected 'file', got: %s", *argv);
|
|
|
|
return -1;
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|
|
|
|
NEXT_ARG();
|
|
|
|
|
2018-03-01 20:20:10 -08:00
|
|
|
if (!strcmp(*argv, "-"))
|
|
|
|
fp = stdin;
|
|
|
|
else
|
|
|
|
fp = fopen(*argv, "r");
|
2017-10-04 20:10:04 -07:00
|
|
|
if (!fp) {
|
2017-10-23 09:24:13 -07:00
|
|
|
p_err("Can't open file (%s): %s", *argv, strerror(errno));
|
2017-10-04 20:10:04 -07:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2017-10-23 09:24:12 -07:00
|
|
|
if (json_output)
|
|
|
|
jsonw_start_array(json_wtr);
|
2017-10-04 20:10:04 -07:00
|
|
|
while (fgets(buf, sizeof(buf), fp)) {
|
2018-03-01 20:20:08 -08:00
|
|
|
cp = strchr(buf, '#');
|
|
|
|
if (cp)
|
|
|
|
*cp = '\0';
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
if (strlen(buf) == sizeof(buf) - 1) {
|
|
|
|
errno = E2BIG;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2018-03-01 20:20:09 -08:00
|
|
|
/* Append continuation lines if any (coming after a line ending
|
|
|
|
* with '\' in the batch file).
|
|
|
|
*/
|
|
|
|
while ((cp = strstr(buf, "\\\n")) != NULL) {
|
|
|
|
if (!fgets(contline, sizeof(contline), fp) ||
|
|
|
|
strlen(contline) == 0) {
|
|
|
|
p_err("missing continuation line on command %d",
|
|
|
|
lines);
|
|
|
|
err = -1;
|
|
|
|
goto err_close;
|
|
|
|
}
|
|
|
|
|
|
|
|
cp = strchr(contline, '#');
|
|
|
|
if (cp)
|
|
|
|
*cp = '\0';
|
|
|
|
|
|
|
|
if (strlen(buf) + strlen(contline) + 1 > sizeof(buf)) {
|
|
|
|
p_err("command %d is too long", lines);
|
|
|
|
err = -1;
|
|
|
|
goto err_close;
|
|
|
|
}
|
|
|
|
buf[strlen(buf) - 2] = '\0';
|
|
|
|
strcat(buf, contline);
|
|
|
|
}
|
|
|
|
|
2018-03-01 20:20:11 -08:00
|
|
|
n_argc = make_args(buf, n_argv, BATCH_ARG_NB_MAX, lines);
|
2017-10-04 20:10:04 -07:00
|
|
|
if (!n_argc)
|
|
|
|
continue;
|
2021-06-09 19:59:16 +08:00
|
|
|
if (n_argc < 0) {
|
|
|
|
err = n_argc;
|
2018-03-01 20:20:11 -08:00
|
|
|
goto err_close;
|
2021-06-09 19:59:16 +08:00
|
|
|
}
|
2017-10-04 20:10:04 -07:00
|
|
|
|
2017-10-23 09:24:12 -07:00
|
|
|
if (json_output) {
|
|
|
|
jsonw_start_object(json_wtr);
|
|
|
|
jsonw_name(json_wtr, "command");
|
|
|
|
jsonw_start_array(json_wtr);
|
|
|
|
for (i = 0; i < n_argc; i++)
|
|
|
|
jsonw_string(json_wtr, n_argv[i]);
|
|
|
|
jsonw_end_array(json_wtr);
|
|
|
|
jsonw_name(json_wtr, "output");
|
|
|
|
}
|
|
|
|
|
2022-10-20 11:03:32 +01:00
|
|
|
err = cmd_select(commands, n_argc, n_argv, do_help);
|
2017-10-23 09:24:12 -07:00
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_end_object(json_wtr);
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
if (err)
|
|
|
|
goto err_close;
|
|
|
|
|
|
|
|
lines++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (errno && errno != ENOENT) {
|
2018-02-14 22:42:55 -08:00
|
|
|
p_err("reading batch file failed: %s", strerror(errno));
|
2017-10-04 20:10:04 -07:00
|
|
|
err = -1;
|
|
|
|
} else {
|
2018-10-20 23:01:49 +01:00
|
|
|
if (!json_output)
|
|
|
|
printf("processed %d commands\n", lines);
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|
|
|
|
err_close:
|
2018-03-01 20:20:10 -08:00
|
|
|
if (fp != stdin)
|
|
|
|
fclose(fp);
|
2017-10-04 20:10:04 -07:00
|
|
|
|
2017-10-23 09:24:12 -07:00
|
|
|
if (json_output)
|
|
|
|
jsonw_end_array(json_wtr);
|
|
|
|
|
2017-10-04 20:10:04 -07:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int main(int argc, char **argv)
|
|
|
|
{
|
2017-10-23 09:24:06 -07:00
|
|
|
static const struct option options[] = {
|
2017-10-23 09:24:07 -07:00
|
|
|
{ "json", no_argument, NULL, 'j' },
|
2017-10-23 09:24:06 -07:00
|
|
|
{ "help", no_argument, NULL, 'h' },
|
2017-10-23 09:24:07 -07:00
|
|
|
{ "pretty", no_argument, NULL, 'p' },
|
2017-10-23 09:24:06 -07:00
|
|
|
{ "version", no_argument, NULL, 'V' },
|
2017-11-08 13:55:49 +09:00
|
|
|
{ "bpffs", no_argument, NULL, 'f' },
|
2018-10-15 11:19:55 -07:00
|
|
|
{ "mapcompat", no_argument, NULL, 'm' },
|
2018-12-18 10:13:19 +00:00
|
|
|
{ "nomount", no_argument, NULL, 'n' },
|
2019-05-24 11:36:46 +01:00
|
|
|
{ "debug", no_argument, NULL, 'd' },
|
2021-05-13 17:36:19 -07:00
|
|
|
{ "use-loader", no_argument, NULL, 'L' },
|
2020-11-04 20:34:01 -08:00
|
|
|
{ "base-btf", required_argument, NULL, 'B' },
|
2017-10-23 09:24:06 -07:00
|
|
|
{ 0 }
|
|
|
|
};
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
bool version_requested = false;
|
2017-10-23 09:24:07 -07:00
|
|
|
int opt, ret;
|
2017-10-23 09:24:06 -07:00
|
|
|
|
2021-12-20 22:45:28 +01:00
|
|
|
setlinebuf(stdout);
|
|
|
|
|
bpftool: Clear errno after libcap's checks
When bpftool is linked against libcap, the library runs a "constructor"
function to compute the number of capabilities of the running kernel
[0], at the beginning of the execution of the program. As part of this,
it performs multiple calls to prctl(). Some of these may fail, and set
errno to a non-zero value:
# strace -e prctl ./bpftool version
prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1
prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1
prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
** fprintf added at the top of main(): we have errno == 1
./bpftool v7.0.0
using libbpf v1.0
features: libbfd, libbpf_strict, skeletons
+++ exited with 0 +++
This has been addressed in libcap 2.63 [1], but until this version is
available everywhere, we can fix it on bpftool side.
Let's clean errno at the beginning of the main() function, to make sure
that these checks do not interfere with the batch mode, where we error
out if errno is set after a bpftool command.
[0] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/libcap/cap_alloc.c?h=libcap-2.65#n20
[1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f25a1b7e69f7b33e6afb58b3e38f3450b7d2d9a0
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220815162205.45043-1-quentin@isovalent.com
2022-08-15 17:22:05 +01:00
|
|
|
#ifdef USE_LIBCAP
|
|
|
|
/* Libcap < 2.63 hooks before main() to compute the number of
|
|
|
|
* capabilities of the running kernel, and doing so it calls prctl()
|
|
|
|
* which may fail and set errno to non-zero.
|
|
|
|
* Let's reset errno to make sure this does not interfere with the
|
|
|
|
* batch mode.
|
|
|
|
*/
|
|
|
|
errno = 0;
|
|
|
|
#endif
|
|
|
|
|
2017-10-23 09:24:06 -07:00
|
|
|
last_do_help = do_help;
|
2017-10-23 09:24:07 -07:00
|
|
|
pretty_output = false;
|
|
|
|
json_output = false;
|
2017-11-08 13:55:49 +09:00
|
|
|
show_pinned = false;
|
2018-12-18 10:13:19 +00:00
|
|
|
block_mount = false;
|
2022-10-20 11:03:00 +01:00
|
|
|
bin_name = "bpftool";
|
2017-10-23 09:24:06 -07:00
|
|
|
|
2017-11-28 17:44:30 -08:00
|
|
|
opterr = 0;
|
2021-11-10 11:23:24 -08:00
|
|
|
while ((opt = getopt_long(argc, argv, "VhpjfLmndB:l",
|
2017-10-23 09:24:06 -07:00
|
|
|
options, NULL)) >= 0) {
|
|
|
|
switch (opt) {
|
|
|
|
case 'V':
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
version_requested = true;
|
|
|
|
break;
|
2017-10-23 09:24:06 -07:00
|
|
|
case 'h':
|
|
|
|
return do_help(argc, argv);
|
2017-10-23 09:24:07 -07:00
|
|
|
case 'p':
|
|
|
|
pretty_output = true;
|
|
|
|
/* fall through */
|
|
|
|
case 'j':
|
2017-11-28 17:44:28 -08:00
|
|
|
if (!json_output) {
|
|
|
|
json_wtr = jsonw_new(stdout);
|
|
|
|
if (!json_wtr) {
|
|
|
|
p_err("failed to create JSON writer");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
json_output = true;
|
|
|
|
}
|
|
|
|
jsonw_pretty(json_wtr, pretty_output);
|
2017-10-23 09:24:07 -07:00
|
|
|
break;
|
2017-11-08 13:55:49 +09:00
|
|
|
case 'f':
|
|
|
|
show_pinned = true;
|
|
|
|
break;
|
2018-10-15 11:19:55 -07:00
|
|
|
case 'm':
|
2019-10-07 15:56:04 -07:00
|
|
|
relaxed_maps = true;
|
2018-10-15 11:19:55 -07:00
|
|
|
break;
|
2018-12-18 10:13:19 +00:00
|
|
|
case 'n':
|
|
|
|
block_mount = true;
|
|
|
|
break;
|
2019-05-24 11:36:46 +01:00
|
|
|
case 'd':
|
|
|
|
libbpf_set_print(print_all_levels);
|
2019-05-24 11:36:48 +01:00
|
|
|
verifier_logs = true;
|
2019-05-24 11:36:46 +01:00
|
|
|
break;
|
2020-11-04 20:34:01 -08:00
|
|
|
case 'B':
|
|
|
|
base_btf = btf__parse(optarg, NULL);
|
2022-11-20 11:26:32 +00:00
|
|
|
if (!base_btf) {
|
|
|
|
p_err("failed to parse base BTF at '%s': %d\n",
|
|
|
|
optarg, -errno);
|
2020-11-04 20:34:01 -08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
break;
|
2021-05-13 17:36:19 -07:00
|
|
|
case 'L':
|
|
|
|
use_loader = true;
|
|
|
|
break;
|
2017-10-23 09:24:06 -07:00
|
|
|
default:
|
2017-11-28 17:44:30 -08:00
|
|
|
p_err("unrecognized option '%s'", argv[optind - 1]);
|
|
|
|
if (json_output)
|
|
|
|
clean_and_exit(-1);
|
|
|
|
else
|
|
|
|
usage();
|
2017-10-23 09:24:06 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
argc -= optind;
|
|
|
|
argv += optind;
|
|
|
|
if (argc < 0)
|
|
|
|
usage();
|
2017-10-04 20:10:04 -07:00
|
|
|
|
bpftool: Add current libbpf_strict mode to version output
+ bpftool --legacy --version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool --version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --legacy --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --help
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool
Usage: bpftool [OPTIONS] OBJECT { COMMAND | help }
bpftool batch file FILE
bpftool version
OBJECT := { prog | map | link | cgroup | perf | net | feature | btf | gen | struct_ops | iter }
OPTIONS := { {-j|--json} [{-p|--pretty}] | {-d|--debug} | {-l|--legacy} |
{-V|--version} }
+ bpftool --legacy version
bpftool v5.15.0
features: libbfd, skeletons
+ bpftool version
bpftool v5.15.0
features: libbfd, libbpf_strict, skeletons
+ bpftool --json --legacy version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":false,"skeletons":true}}
+ bpftool --json version
{"version":"5.15.0","features":{"libbfd":true,"libbpf_strict":true,"skeletons":true}}
Suggested-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/20211116000448.2918854-1-sdf@google.com
2021-11-15 16:04:48 -08:00
|
|
|
if (version_requested)
|
|
|
|
return do_version(argc, argv);
|
|
|
|
|
2022-10-20 11:03:32 +01:00
|
|
|
ret = cmd_select(commands, argc, argv, do_help);
|
2017-10-23 09:24:07 -07:00
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_destroy(&json_wtr);
|
|
|
|
|
2020-11-04 20:34:01 -08:00
|
|
|
btf__free(base_btf);
|
tools: bpftool: show filenames of pinned objects
Added support to show filenames of pinned objects.
For example:
root@test# ./bpftool prog
3: tracepoint name tracepoint__irq tag f677a7dd722299a3
loaded_at Oct 26/11:39 uid 0
xlated 160B not jited memlock 4096B map_ids 4
pinned /sys/fs/bpf/softirq_prog
4: tracepoint name tracepoint__irq tag ea5dc530d00b92b6
loaded_at Oct 26/11:39 uid 0
xlated 392B not jited memlock 4096B map_ids 4,6
root@test# ./bpftool --json --pretty prog
[{
"id": 3,
"type": "tracepoint",
"name": "tracepoint__irq",
"tag": "f677a7dd722299a3",
"loaded_at": "Oct 26/11:39",
"uid": 0,
"bytes_xlated": 160,
"jited": false,
"bytes_memlock": 4096,
"map_ids": [4
],
"pinned": ["/sys/fs/bpf/softirq_prog"
]
},{
"id": 4,
"type": "tracepoint",
"name": "tracepoint__irq",
"tag": "ea5dc530d00b92b6",
"loaded_at": "Oct 26/11:39",
"uid": 0,
"bytes_xlated": 392,
"jited": false,
"bytes_memlock": 4096,
"map_ids": [4,6
],
"pinned": []
}
]
root@test# ./bpftool map
4: hash name start flags 0x0
key 4B value 16B max_entries 10240 memlock 1003520B
pinned /sys/fs/bpf/softirq_map1
5: hash name iptr flags 0x0
key 4B value 8B max_entries 10240 memlock 921600B
root@test# ./bpftool --json --pretty map
[{
"id": 4,
"type": "hash",
"name": "start",
"flags": 0,
"bytes_key": 4,
"bytes_value": 16,
"max_entries": 10240,
"bytes_memlock": 1003520,
"pinned": ["/sys/fs/bpf/softirq_map1"
]
},{
"id": 5,
"type": "hash",
"name": "iptr",
"flags": 0,
"bytes_key": 4,
"bytes_value": 8,
"max_entries": 10240,
"bytes_memlock": 921600,
"pinned": []
}
]
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-08 13:55:48 +09:00
|
|
|
|
2017-10-23 09:24:07 -07:00
|
|
|
return ret;
|
2017-10-04 20:10:04 -07:00
|
|
|
}
|