On 12/14, Quentin Monnet wrote: > 2018-12-13 12:19 UTC+0000 ~ Quentin Monnet <quentin.mon...@netronome.com> > > 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: > > > > So as a reminder this one comes from an actual probe with the syscall... > > > - Availability of bpf() system call > > ... those 4 are read from procfs... > > > - 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 > > ... these are read from /boot/config-$(uname -r)... > > > - Status of kernel compilation options related to BPF features > > ... this from uname()... > > > - Release number of the running kernel > > ... and the remaining ones are probed with minimal BPF programs. > > > - Availability of known eBPF program types > > - Availability of known eBPF map types > > - Availability of known eBPF helper functions > > As discussed with Stanislav and Daniel, some of the probing should > probably be moved to libbpf instead for the next version of this set. As > I see it, I could move probing to libbpf for: > > - BPF prog and map types > - BPF helper functions > - bpf() syscall availability > > I do not think kernel compile options, or kernel release number, should > go to libbpf, they're probably better in bpftool. I'm unsure about the +1 Kernel + /proc stuff can probably live in bpftool.
> procfs parameters, I'm considering leaving them in bpftool for now. Do > others have an opinion about this? Maybe start with adding prog/map/helpers probes to the libbpf (+ifindex)? > > Quentin
