On Thu, Aug 06, 2020 at 03:42:23PM +0100, Alan Maguire wrote:
The bpf_trace_printk tracepoint is augmented with a "trace_id" field; it is used to allow tracepoint filtering as typed display information can easily be interspersed with other tracing data, making it hard to read. Specifying a trace_id will allow users to selectively trace data, eliminating noise.
Since trace_id is not seen in trace_pipe, how do you expect users to filter by it? It also feels like workaround. May be let bpf prog print the whole struct in one go with multiple new lines and call trace_bpf_trace_printk(buf) once?
Also please add interface into bpf_seq_printf. BTF enabled struct prints is useful for iterators too and generalization you've done in this patch pretty much takes it there.
+/*
- Options to control show behaviour.
- BTF_SHOW_COMPACT: no formatting around type information
- BTF_SHOW_NONAME: no struct/union member names/types
- BTF_SHOW_PTR_RAW: show raw (unobfuscated) pointer values;
equivalent to %px.
- BTF_SHOW_ZERO: show zero-valued struct/union members; they
are not displayed by default
- BTF_SHOW_NONEWLINE: include indent, but suppress newline;
to be used when a show function implicitly includes a newline.
- BTF_SHOW_UNSAFE: skip use of bpf_probe_read() to safely read
data before displaying it.- */
+#define BTF_SHOW_COMPACT (1ULL << 0) +#define BTF_SHOW_NONAME (1ULL << 1) +#define BTF_SHOW_PTR_RAW (1ULL << 2) +#define BTF_SHOW_ZERO (1ULL << 3) +#define BTF_SHOW_NONEWLINE (1ULL << 32) +#define BTF_SHOW_UNSAFE (1ULL << 33)
I could have missed it earlier, but what is the motivation to leave the gap in bits? Just do bit 4 and 5 ?