From: Steven Rostedt <rostedt@goodmis.org>
To: Aaron Tomlin <atomlin@atomlin.com>
Cc: mhiramat@kernel.org, mark.rutland@arm.com,
mathieu.desnoyers@efficios.com, corbet@lwn.net, sean@ashe.io,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [v3 PATCH 0/1] tracing: Add bitmask-list option for human-readable bitmask display
Date: Sat, 10 Jan 2026 16:10:21 -0500 [thread overview]
Message-ID: <20260110161021.2aa5f19c@gandalf.local.home> (raw)
In-Reply-To: <sm4xoemzv7d5pkyudybpxydriukvnlkwiaxrbh3qgevpnxphha@x7gberqhyjdo>
On Sat, 10 Jan 2026 16:06:02 -0500
Aaron Tomlin <atomlin@atomlin.com> wrote:
> On Fri, Dec 26, 2025 at 11:07:23AM -0500, Aaron Tomlin wrote:
> > Hi Steve,
> >
> > This patch adds 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.
> >
> > This iteration incorporates the use of iter->tmp_seq to ensure the
> > implementation is robust, instance-aware, and free from buffer contention
> > or duplication issues.
> >
> > Please let me know your thoughts.
>
> Hi Steve,
>
> I would like to ask if this iteration is suitable for inclusion, or should
> any further refinements be made?
>
You can always check the status of a patch from patchwork. This one is here:
https://patchwork.kernel.org/project/linux-trace-kernel/patch/20251226160724.2246493-2-atomlin@atomlin.com/
The states are:
New - I haven't looked at it.
Under Review - I have it in a local queue (can still be rejected)
Queued - It's moved to linux-next
Accepted - It's in Linus's tree
Other states I will most likely have a response to.
This one is currently in the "Under Review" state. It also means I haven't
found anything wrong with it. It just hasn't gone through all my tests.
-- Steve
>
> Kind regards,
prev parent reply other threads:[~2026-01-10 21:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-26 16:07 [v3 PATCH 0/1] tracing: Add bitmask-list option for human-readable bitmask display Aaron Tomlin
2025-12-26 16:07 ` [v3 PATCH 1/1] " Aaron Tomlin
2026-01-10 21:06 ` [v3 PATCH 0/1] " Aaron Tomlin
2026-01-10 21:10 ` Steven Rostedt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260110161021.2aa5f19c@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=atomlin@atomlin.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=sean@ashe.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox