On Tue, 08 Sep 2026 10:15:09 +0900 Masami Hiramatsu (Google) <[email protected]> wrote: > BTW, to make it easier for review, can you split the patches in > several parts? For example, start from a minimum basic functionality > (just internal stackmap, seq_read, and reset), use it from tracing, > add stat interface, binary interface, and documents, tools, selftests. > This makes the series in at least 7 patches, but nicer to focus on > one thing for each patch.
Agreed, and the split points you list match where the current patches are doing several things at once. v7 will follow that structure: 1. internal stackmap: table, element pool, get_id(), create/destroy 2. text seq_file export and reset 3. use it from the ftrace stack recording path 4. stat interface 5. binary interface 6. ftrace_stackmap.bits= kernel parameter 7. documentation 8. userspace parser 9. selftest: basic functionality 10. selftest: reset semantics and binary ABI header 11. selftest: top-level instance gating Each patch compiles on its own and does not leave unused helpers or tracefs files whose backing code has not been added yet. Patches 4 and 5 also carry the stat locking fix and the binary export rework from your comments on 1/3, so those interfaces arrive in the shape you asked for rather than being split first and fixed afterwards. > The patch description is a key area to focus on; if the explanation > proceeds by saying "add Foo, then add Bar, and so on," those changes > should likely be split into multiple patches. That test also flags the current 1/3 and 3/3 accurately. Both of their descriptions are lists of independent additions, which is why they grew to 949 and 614 lines. I will use it as the check when writing the v7 descriptions: if a description needs a bullet list of additions, the patch is still too coarse. Pengfei
