drzaeus77

The function call infra being added doesn't change the current DAG restrictions, meaning that the functions are verified using a whole-program analysis semantic, so it may end up working more as just a code organization tool than something fundamental. There is already an ability to tail call to other bpf functions, which does more of what you're thinking, and the bpf runtime enforces a limit of 32 of those tail calls.

The helpers are in http://elixir.free-electrons.com/linux/v4.15-rc3/source/kern.... See the field gpl_only. For the list of which helpers are available in which hooks, the code needs to be read, to find things like: http://elixir.free-electrons.com/linux/v4.15-rc3/source/net/....

Unfortunately, I don't believe the high level list of which hooks have gpl helpers is published, so reading the code is the best method currently.

The first BPF programs (original tcpdump use case) were always proprietary-compatible. If you think about it, there is nothing linux-specific about networking, and any code the user writes to tweak the data that is traversing their machine should be theirs to write, and doesn't taint the kernel. The same can be said for iptables/nft rules (you don't have to GPL your firewall configuration). Therefore, the BPF hooks that deal with packets (XDP, tc, socket) are not GPL-restricted and will remain so in the future.

Where GPL comes in is when you use BPF to introspect the kernel. It is quite possible to use BPF programs with the kprobe hook to extract data about how the kernel itself works, and the opinion of the kernel developers on this is that such use cases are within the realm of GPL protection.

That's right, although work is being done to improve the situation. The first is the ability to have function calls: https://patchwork.ozlabs.org/cover/848824/. This won't allow loops, but will allow for less inline boilerplate. Building on this base infra, some folks are working to add a loop counter based verification rather than forcing the user to unroll manually.

Hopefully you don't have to wait!

We're really hoping that this set of tools has only the minimal requirements, that being the kernel.

Since Clang/LLVM can be linked as a static or dynamic library, we only have a build-time dependency on those, and opt for the static library. The build scripts have steps to build clang+llvm from source if your distro doesn't include it. The binaries that we ship hide this and should (if we've done things right) only have a libc and few misc .so dependencies. A change under test even adds a fully static lua version.

On the kernel side, we don't conditionally compile anything based on kernel features, and instead try/fail at runtime. You can just upgrade your kernel and the tools will start to take advantage of the new features immediately.

Exactly, it is using bpf_probe_read. Internally, BCC uses clang's Rewriter functionality to mangle valid C (but invalid BPF) into valid C with bpf helper functions.

The req->rq_disk->disk_name expression would expand into:

({ typeof(char [32]) _val; memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (u64)({ typeof(struct gendisk *) _val; memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (u64)req + offsetof(struct request, rq_disk)); _val; }) + offsetof(struct gendisk, disk_name)); _val; }));

If you are playing with the tools, the BPF() class takes an optional argument debug=, where bit 2 (0x4) will print the rewritten C output for your edification.

Author of BCC here... I hadn't seen shark before, but the mindset does appear similar.

A couple comparison points I noticed while briefly investigating shark:

C code is passed to clang+llc as external calls, whereas in BCC clang+llvm are statically linked in.

Both support native (lua/python) bindings to the eBPF maps.

In shark, I don't see that it is easy to dereference kprobe'd function arguments, as it is in `bpf_trace_printk("1 W %s %d %d ?\\n", req->rq_disk->disk_name, ...)` of <bcc>/tools/biosnoop.

This should also answer your last question, which was where is "%s" used. tools/opensnoop also uses string printks.

Comparison points aside, I intentionally made sure that the clang legwork that is being done in BCC is wrapped with a C api, so any language bindings besides python should be trivial to implement. It would be ideal (in my mind) if shark could leverage libbcc and make both tools better in the process.