Re: [RFC PATCH v6 3/3] trace: add documentation, selftest and tooling for stackmap
From: Pengfei Li
Date: Mon Sep 07 2026 - 23:15:18 EST
On Tue, 08 Sep 2026 10:35:14 +0900 Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote:
> Could you decouple tools/docs/tests in independent patches?
Yes. v7 splits this patch into the documentation, the userspace parser,
and the tests, each on its own.
> If each test has this volume description, it is enough to split those
> tests in independent patches.
Fair point -- the three tests cover unrelated properties and each needed
its own paragraph, which is the same signal you mentioned on the cover.
They become three patches in v7:
- basic functionality: stack_id events are produced and the map fills
- reset semantics: the map is cleared while the ring buffer is not,
plus the binary ABI header check
- instance gating: a secondary instance exposes neither the option
nor the stack_map* nodes, and writing the option there is rejected
Each lands after the interface it exercises, so no test references a
tracefs file that does not exist yet at that point in the series. The
reset test's ABI header check follows the binary export patch, which is
being reworked to a streaming seq_file export per your comment on 1/3,
so the check will match the final header layout.
> > + with open(args.file, 'rb') as f:
> > + data = f.read()
>
> nit: Can this support input from stdin? If we use this on android,
> user may want to do:
>
> adb shell cat /sys/.../stack_map_bin | python3 stackmap_dump.py
Good use case, and it is the common one on Android where pulling the
file first is an extra step. v7 makes the path argument optional and
reads sys.stdin.buffer when it is omitted or given as '-', so both
adb shell cat /sys/.../stack_map_bin | stackmap_dump.py
stackmap_dump.py /tmp/stack_map.bin
work. Reading from a pipe also suits the streaming export better than
the current stat-and-read pattern.
Pengfei