Designing better kernel ABIs [LWN.net]

Designing better kernel ABIs

Posted Oct 27, 2016 3:12 UTC (Thu) by deater (subscriber, #11746)
Parent article: Designing better kernel ABIs

I'm currently trying to document a newish feature in one complex interface (perf_event_open) that interacts with an even worse interface (eBPF). Fun times.

The feature is not documented well, the sample code in the kernel commit that introduced the feature doesn't actually work, and the relevant bpf manpage section just says "to be documented".

The only plausible option is to try to reverse engineer what the "perf" tool does. Take a look at the perf code sometime, large sections of it have not a single code comment, and have fun things where bpf_object_load() calls bpf_object__load_progs() calls bpf_program__load() which calls load_program() which calls bpf_load_program() and eventually you just give up.

to post comments

Designing better kernel ABIs

Posted Oct 27, 2016 23:46 UTC (Thu) by zlynx (guest, #2285) [Link]

I've often seen that in Java programs where there's some rule that certain modules can only talk to certain limited other modules.

So the programmer, instead of making a direct call from Module A to Module D has to call B, which calls C, which finally calls D.

And that's the simple form. Once a Java "architect" gets involved and the code goes all "dependency inversion" you have the above problem plus XML files.

But it sure does look pretty and organized in a graph with little dotted boxes around the modules.