On Thu, 25 Dec 2025 02:38:03 -0500 Aaron Tomlin <[email protected]> wrote:
> On Wed, Dec 24, 2025 at 08:58:48AM -0500, Steven Rostedt wrote: > > 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
