Thanks for the review. I have rewritten the local commit message around the missing capability: map event_pipe currently accepts only perf event arrays, leaving no built-in way to inspect records produced through the BPF ring buffer API. It now explains the callback's -EINTR return as well: a producer can keep ring_buffer__poll() busy after a stop signal, so checking only the outer loop is insufficient. These message changes are ready for the next full revision.
In the manual, "raw bytes" describes the payload without schema/BTF decoding; hexadecimal is the stated plain-text representation of those bytes. It is not intended to mean binary stdout. Likewise, the shared consumer position explains why using this command affects another consumer, while the passive-view warning states the user-visible risk. The wording could be shorter, but I do not see a semantic contradiction and am retaining the explicit consumption warning for now. For completion, exact matching is intentional: a bare ringbuf pattern would also match user_ringbuf, which event_pipe rejects. The current expression matches the complete JSON type field and avoids that problem. Moving exact matching into both common helpers is a reasonable cleanup, but changes all their callers; using two calls also lists the maps twice. I am keeping this feature's localized, single-listing change rather than expanding it into a shared-helper refactor. I agree that using sig_atomic_t and removing fprintf() from the handler also harden the existing perf path, and could form a preparatory patch. The current combined patch keeps the shared handler safe while retaining the stopping diagnostic in normal control flow. I am keeping that organization for now; I can split it if the maintainer prefers separate review/backport handling. There is no remaining unsafe fprintf() in the handler in the submitted patch.
