Allow modules to define their own ebpf programs?

[amorenoz]

While writing #90 I found myself what seemed to be abusing the Probe+Hook system.

It might be specific to OVS module or it might be needed by other modules, that's something to discuss but for me it was clear that some of the hooks I was attaching to some probes didn't need to be hooks.

The main use case was to add a small ebpf program that creates some context (and, say, stores it in a map) and maybe another program later on that clears it. These programs do not send events but need to share the map fd with the hook that will retrieve this context to enrich the event it sends.

Some open questions:

• First, of course, is this usecase something we want to allow.
• Would filtering be available? How?
• Would the module open, load and attach it's own program or would it register the program somehow with the core infrastructure so we can centrally track what are we attaching where.

[amorenoz]

Discussed in the weekly meeting and concluded:

• We should try not to use per-module ebpf programs because sharing common infrastructure is complicated
• Hooks will be able to opt-in and opt-out of filtering so it should not be a problem to implement whatever functionality as hooks
• Some ideas to get multiple hooks in the same file:
  • Make the same file be compiled several times by build.rs with some different -D options
  • Use a per-module (private) map or array to store a ksym->ANY data and, within the (single) hook check this data and branch out
• It's OK for the hook to not send events
• Having everything as hooks is good for consistency and error reporting.