[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251223133452.416fd539@gandalf.local.home>
Date: Tue, 23 Dec 2025 13:34:52 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: mhiramat@...nel.org, mark.rutland@....com,
mathieu.desnoyers@...icios.com, corbet@....net, sean@...e.io,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH] tracing: Add bitmask-list option for human-readable
bitmask display
On Mon, 22 Dec 2025 22:56:22 -0500
Aaron Tomlin <atomlin@...mlin.com> wrote:
> Add support for displaying bitmasks in human-readable list format (e.g.,
> 0,2-5,7) in addition to the default hexadecimal bitmap representation.
> This is particularly useful when tracing CPU masks and other large
> bitmasks where individual bit positions are more meaningful than their
> hexadecimal encoding.
>
> When the "bitmask-list" option is enabled, the printk "%*pbl" format
> specifier is used to render bitmasks as comma-separated ranges, making
> trace output easier to interpret for complex CPU configurations and
> large bitmask values.
Hmm, I have a couple of issues with this change. One, this is global. It
affects all instances. The other is that if this is going to be done, then
instead of adding a parameter to trace_seq_bitmask(), another trace_seq_*
API should be created. Perhaps trace_seq_bitmask_cnt()? And have
trace_print_bitmask_seq() call them separately.
I'm still not convinced that this is needed. What examples do you see?
Should it be only for CPU bitmasks?
I think a bit more thought needs to be made on a change like this. There's
other options that were added that I now regret. I don't want to add
another one I wish we didn't have.
-- Steve
Powered by blists - more mailing lists