2018-12-14 10:21 UTC-0800 ~ Stanislav Fomichev <s...@fomichev.me> > 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)?
Agree with it, I'll work on a new version for next week. Thanks!
