Re-thinking BPF logging ======================= BPF historically had a very restricted logging capabilities through bpf_printk macro. It's almost never used in production due to its limitations and because of how heavy-weight it is. BPF developers would just sprinkle few logging statements here and there while debugging issue, and will immediately remove them once they are done. But real-world production BPF applications need easy-to-use and flexible logging capabilities, both for debugging at scale in production, as well as for ad-hoc local development needs. Its hard to anticipate what needs to be logged in case of production issue, so logging has to be shipped with production version of BPF application, but enabled whenever issue arises. BPF needs to re-think its logging approach to satisfy real-world needs: zero-overhead when disabled, low-overhead and reliable while turned on. All this without sacrificing code clarity and developer productivity. We pose that with all the recent BPF advancements (BTF, global variables, BPF text poking, etc), it's now possible to have a qualitatively different logging capabilities in a modern BPF application. -- Andrii
