From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnaldo Carvalho de Melo Subject: Re: [PATCH bpf-next 0/8] tools: bpftool: add probes for system and device Date: Fri, 14 Dec 2018 11:00:09 -0300 Message-ID: <20181214140009.GS21027@kernel.org> References: <20181213121922.6652-1-quentin.monnet@netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexei Starovoitov , Daniel Borkmann , netdev@vger.kernel.org, oss-drivers@netronome.com, Jesper Dangaard Brouer , Stanislav Fomichev To: Quentin Monnet Return-path: Received: from mail.kernel.org ([198.145.29.99]:35998 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728881AbeLNOAN (ORCPT ); Fri, 14 Dec 2018 09:00:13 -0500 Content-Disposition: inline In-Reply-To: <20181213121922.6652-1-quentin.monnet@netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: Em Thu, Dec 13, 2018 at 12:19:14PM +0000, Quentin Monnet escreveu: > Hi, > This set add a new command to bpftool in order to dump a list of > eBPF-related parameters for the system (or for a specific network > device) to the console. Once again, this is based on a suggestion from > Daniel. > > At this time, output includes: > > - Availability of bpf() system call > - Availability of bpf() system call for unprivileged users > - JIT status (enabled or not, with or without debugging traces) > - JIT hardening status > - JIT kallsyms exports status > - Status of kernel compilation options related to BPF features > - Release number of the running kernel > - Availability of known eBPF program types > - Availability of known eBPF map types > - Availability of known eBPF helper functions > > There are three different ways to dump this information at this time: > > - Plain output dumps probe results in plain text. It is the most > flexible options for providing descriptive output to the user, but > should not be relied upon for parsing the output. > - JSON output is supported. > - A third mode, available through the "macros" keyword appended to > the command line, dumps the parameters as a series of "#define" > directives, that can be included into a C header file for example. > > If the user does not have root privileges (or more precisely, the > CAP_SYS_ADMIN capability) detection will be erroneous for most > parameters. Therefore, forbid non-root users to run the command. One other thing I noticed is that this has lots of goodies that are not bpftool specific, like the json writer, the procfs reading routines, etc. perf has these and some were even moved to tools/lib/api/, things like finding the procfs, debugfs, sysfs mount points, routines to mount then automatically when the user can do it, etc. Have you considered using them? If so, what prevented you from doing it? Licensing? Sharing these non-tool specific routines in tools/lib/ is a good thing and we should work out details on what prevents that from happening. Another thing that came to mind is that the bpf loaded in perf has routines for figuring out the kbuild directory, kernel version, etc. Please take a look at tools/perf/util/llvm-utils.c and tools/perf/util/bpf-loader.c. If we could reuse what is there, working out licensing details with Wang, etc, that would be awesome. - Arnaldo