[1/2] Add flavor-specific log codegen callback

[yaakov-stein]

Gave stack-pr a try, but it doesn't allow for multi-commit PR's :(

Stack:

• [0/2] Refactor Logging Infrastructure #485
• -> [1/2] Add flavor-specific log codegen callback #486
• [2/2] Add CGROUP_SOCK_ADDR Logging Infrastructure #491

Summary

The main goal here is to add a callback that gives flavors the ability to more finely control the logging process. This will enable us to easily use a new CGROUP_SOCK_ADDR elf-stub.

Notes

• Moves cgen/matcher/packet.{c,h} to cgen/packet.{c,h}. It was a mistake to put this here in the first place as packet-based flavors can share more than matcher codegen. We correct the placement now.
• Once again, no functional change. This moves a file around and add a callback.

[github-actions]

Claude review of PR #486 (5cc7d36)

This PR has already received thorough review (24 inline comments across multiple iterations). Most substantive issues were previously identified. The findings below are new items not covered by existing comments.

Suggestions

• bf_log_sock_addr padding hole — src/libbpfilter/include/bpfilter/runtime.h:146 — 2-byte implicit padding between dport and comm due to bf_aligned(8); consider explicit padding or field reorder before the follow-up PR locks in the layout

Nits

• System header grouping — src/libbpfilter/include/bpfilter/runtime.h:26 — <linux/in6.h> and <asm/types.h> separated by blank line; both are system headers and belong in the same group
• Misleading byteorder Doxygen — src/libbpfilter/include/bpfilter/runtime.h:186 — union doc says "raw packet headers in network byteorder" but bf_log_pkt also contains host-byteorder fields (pkt_size, req_headers, headers)

Workflow run

[github-actions]

Claude: suggestion: <linux/in6.h> is needed only for sizeof(struct in6_addr) in struct bf_log_sock_addr, which has no producers or consumers yet (part 2/2). It widens the include set for all BPF stubs and all files that include runtime.h. Consider using __u8 saddr[16] / __u8 daddr[16] instead to avoid pulling in the header.

Also, <linux/in6.h> and <asm/types.h> are both system headers but are separated by a blank line, breaking the include-group convention from the style guide.

[github-actions]

Claude: nit: <linux/in6.h> and <asm/types.h> are both system headers but are separated by a blank line, which per the style guide implies different include groups. Group them together:

#include <asm/types.h>
#include <linux/in6.h>

Note that <linux/in6.h> transitively includes <linux/types.h> (which pulls in <asm/types.h>), so the explicit <asm/types.h> may now be redundant -- but that is a separate cleanup.

[github-actions]

Claude: suggestion: struct bf_log_sock_addr has a 2-byte implicit padding hole between dport (offset 4+2=6) and comm (offset 8, due to bf_aligned(8)). When a BPF stub eventually populates this struct via bpf_ringbuf_reserve, those 2 padding bytes will contain stale ring buffer content.

Consider making the hole explicit with a __u16 _pad field (and zeroing it in the BPF writer), or reordering fields to eliminate it. Since this struct has no producer yet, now is the cheapest time to adjust the layout.

[github-actions]

Claude: nit: The union Doxygen says use pkt -- raw packet headers in network byteorder, but struct bf_log_pkt also contains pkt_size, req_headers, and headers which are all in host byteorder. Only the raw header byte arrays (l2hdr, l3hdr, l4hdr) are in network byteorder. Consider rewording to match the top-level struct bf_log doc which correctly says "All fields are stored in host byteorder unless noted otherwise."