link: tracepoint support

[lmb]

link: add perf event tracepoint support

Allow attaching to perf event fd based tracepoints (which are
different than raw tracepoints).

Fixes #83

link: check program type for raw tracepoints

Return a more useful error message when passing a program with
the wrong type. This is especially useful here because it's
easy to mix up tracepoints and raw tracepoints.

link: allow Update to return ErrNotSupported

Raw tracepoints don't allow updating the program, yet they use
the bpf_link infrastructure. Allow Update to return ErrNotSupported
for that reason.

[lmb]

cc @mythi @tqbf

[florianl]

Function-wise the PR looks fine for me.
Tracepoints are just one thing, where eBPF programs can be attached to using the perf API. And there are more things, like software and hardware events, that also use this API to attach eBPF programs.
So my concern is, will this package concentrate on the eBPF side or should it also be a wrapper for the perf API?

Personally I would prefer, if this package concentrates purely on the eBPF part. There is already example code that illustrates and documents how this eBPF package can be used with the perf API.
There are other packages like https://github.com/elastic/go-perf, that provide a nice interface to the perf API, if one doesn't want to use the low level calls.

[lmb]

Personally I would prefer, if this package concentrates purely on the eBPF part.

Agreed. My main concern is to give a hand to newcomers when it comes to "how do I attach program XYZ". I really don't know much about tracepoints, I just figured that the example you added covers the use case. So maybe the better thing would be to rewrite the example to use the perf package you linked (which fork though?) and make sure it's prominent in the package documentation?

[florianl]

The existing example on tracepoints is sufficient, I think. It is also linked with the related buzzword in the documentation of this package: https://pkg.go.dev/github.com/cilium/ebpf#example-package-Tracepoint
Maybe a second example which loads an eBPF specification from spec, instead of writing eBPF instructions, would help?

[lmb]

I've split out the raw tracepoint cleanups into #189 while I ponder what to do here.

@florianl I'd prefer if the example were a bit safer, raw FDs flying around aren't really a recipe for success. At the same time I don't want to shoulder the burden of a complicated API, basically what is in this PR is the maximum. What I don't know, since I'm not using tracepoints: would this code be enough for 90% of BPF on tracepoint usage? If yes it's worth it to me, if not we have our answer as well.

[florianl]

sorry for my late reply 🙏 is/was a busy week.

I can provide another example for tracepoints with the github.com/elastic/go-perf API.
I don't think the suggested code in this PR change would cover 90% of use cases.

[florianl]

I have created PR #190 to demonstrate how github.com/elastic/go-perf can be used to attach an eBPF program to a tracepoint.

[lmb]

Thanks! I've been pretty busy as well, so no worries at all.

Let's close this PR.

[ti-mo]

Going to do another take on this with the intention of adding kprobe and uprobe support later on.

[ti-mo]

Continuing this in #265.