Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display

On Thu, 25 Dec 2025 02:38:03 -0500
Aaron Tomlin [off-list ref] wrote:

On Wed, Dec 24, 2025 at 08:58:48AM -0500, Steven Rostedt wrote:

quoted

Should we just make all cpu bitmask range lists instead?  

Hi Steve,

I am somewhat hesitant to adopt that suggestion as I would prefer to avoid
breaking any existing tooling that relies upon the default hexadecimal
bitmask format.

I am too. But the "do not break user space" rule is basically, "it's only
broken if user space notices". If people complain about the change, we can
always revert it ;-)

Whilst range lists are undoubtedly superior for human interpretation, the
hexadecimal output is a well-established standard throughout the kernel.
For instance, the hexadecimal format is still strictly adhered to for
"Cpus_allowed:" within /proc/[pid]/status. Introducing a global change to
ftrace defaults could disrupt parsers and scripts that expect this
consistency across the system.

Really, any scripts that parse the ASCII output is broken by design, as
things change there all the time, and it can be really slow to read.
There's a binary interface for such things. Heck, I bet this change would
probably make the scripts simpler, as searching ranges is easier to parse
than a hex number.

By leveraging the existing bitmask-list trace option via
trace_print_bitmask_seq(), we offer users the requisite flexibility for
high-core-count systems whilst preserving backward compatibility for the
wider ecosystem.

Perhaps it should only be cpumask-list, and only touch bitmasks that are
CPU lists. Although, right now I only see one user of the bitmask code, and
it's using it on a cpumask. Perhaps we should change it to use the cpumask.

There's not many users of the bitmask in tracepoints, and it is mostly with
the new IPI tracepoints (Cc'ing Valentin to get his throughts).

I shall send a new version of the patch shortly. This version incorporates
the use of iter->tmp_seq to ensure the implementation is robust,
instance-aware, and free from buffer contention or duplication issues.

Thanks,

-- Steve