2018-12-15 00:35 UTC+0100 ~ Daniel Borkmann <dan...@iogearbox.net>
> On 12/13/2018 01:19 PM, Quentin Monnet wrote:
>> Add a new component and command for bpftool, in order to probe the
>> system to dump a set of eBPF-related parameters so that users can know
>> what features are available on the system.
>>
>> Parameters are dumped in plain or JSON output (with -j/-p options).
>> Additionally, a specific keyword can be used to provide a third possible
>> output so that the parameters are dumped as #define-d macros, ready to
>> be saved to a header file and included in an eBPF-based project.
>>
>> The current patch introduces probing of two simple parameters:
>> availability of the bpf() system call, and kernel version. Later commits
>> will add other probes.
>>
>> Sample output:
>>
>> # bpftool feature probe kernel
>> Scanning system call and kernel version...
>> Kernel release is 4.19.0
>> bpf() syscall is available
>>
>> # bpftool --json --pretty feature probe kernel
>> {
>> "syscall_config": {
>> "kernel_version_code": 267008,
>> "have_bpf_syscall": true
>> }
>> }
>>
>> # bpftool feature probe kernel macros prefix BPFTOOL_
>> /*** System call and kernel version ***/
>> #define BPFTOOL_LINUX_VERSION_CODE 267008
>> #define BPFTOOL_BPF_SYSCALL
>>
>> The optional "kernel" keyword enforces probing of the current system,
>> which is the only possible behaviour at this stage. It can be safely
>> omitted.
>>
>> The feature comes with the relevant man page, but bash completion will
>> come in a dedicated commit.
>>
>> Signed-off-by: Quentin Monnet <quentin.mon...@netronome.com>
>> Reviewed-by: Jakub Kicinski <jakub.kicin...@netronome.com>
>
> First of all, thanks a lot for working on this infra!
> Few comments below.
>
> [...]
>> +/* Probing functions */
>> +
>> +static int probe_kernel_version(const char *define_prefix)
>> +{
>> + int version, subversion, patchlevel, code = 0;
>> + struct utsname utsn;
>> +
>> + if (!uname(&utsn))
>> + if (sscanf(utsn.release, "%d.%d.%d",
>> + &version, &subversion, &patchlevel) == 3)
>> + code = (version << 16) + (subversion << 8) + patchlevel;
>> +
>> + if (json_output)
>> + jsonw_uint_field(json_wtr, "kernel_version_code", code);
>> + else if (define_prefix)
>> + printf("#define %sLINUX_VERSION_CODE %d\n",
>> + define_prefix, code);
>> + else if (code)
>> + printf("Kernel release is %d.%d.%d\n",
>> + version, subversion, patchlevel);
>> + else
>> + printf("Unable to parse kernel release number\n");
>> +
>> + return code;
>> +}
>
> What would be the use-case to try to fetch the kernel version? My main
> worry is that this doesn't tell much to the user e.g. in kernels where
> features are mainly backported like RHEL. (Is it for the kprobes version
> requirement?)
Yes, I retrieved the kernel version number for testing the kprobes. And
since I had it, I thought I could as well present it to the user. It's
not supposed to tell what features are supported exactly, but I was
thinking that depending on the context, it can help debug things.
