Re: [PATCH RFC 00/11] rust: add support for dynamic debug

On Tue, 20 Oct 2026 23:36:56 +0200
Thomas Weißschuh [off-list ref] wrote:

On 2026-10-20 21:25:42+0300, Zhi Wang wrote:

quoted

On Tue, 20 Oct 2026 19:30:33 +0200
Thomas Weißschuh [off-list ref] wrote:

quoted

+To: Zhi Wang

Thanks Alex for bridge the threads together!

Hey Thomas,

Thanks for the comparison! As a user of this feature, I'm happy to
combine the two series and see this making progress.

The Bounded types, bitfield tests, and module_path!() fallback look
like useful additions. One clarification: with CONFIG_JUMP_LABEL,
our disabled path already has no FFI call.
static_branch_unlikely!() is sufficient for our initially disabled
callsites, including enabling them at runtime.

Ack. Although adding jump label support as a later step would make the
patches smaller and easier to review.

quoted

For the combined series, I'd like to retain these behaviors:

- Debug logging is independent of debug_assertions, starts disabled,
  and is controlled through dynamic debug. IMHO, fewer distro
kernels are compiled with CONFIG_RUST_DEBUG_ASSERTIONS=y nowadays.
(At least, Arch and Fedora are compiled with N)

Ack. It would still be useful to also support default-enabled
callsites, like the C version does. What about '--cfg DEBUG'?

Agree.

quoted

- Disabled pr_debug!()/dev_dbg!() calls do not evaluate their
  arguments. IMHO, it seems the current dev_dbg!() in your patch
  evaluates the params before checking the switch on/off.
(pr_debug()! looks fine though)

As far as I understand, fmt!() itself does not yet evaluate the
expressions passed as arguments. It only typechecks and
creates the precompiled Arguments<'_> structure. The parameters'
Display traits are only executed when the Arguments<'_> is written
somewhere. IMO the typechecking should be done even if the code is
going to be compiled out. Similar to no_printk() on the C side.

I encountered this problem by chance while developing my patches and
testing it on nova-core (unexpected evaluation of a register operation
while dynamic debug is off). IMHO, it seems constructing Arguments
evaluates the expressions immediately even if the resulting arguments
are never formatted.

I made a test on top of your WIP branch, the example is:

pr_debug!("dyndbg repro pr: {}\n", read_status(&reads, &formats));
dev_dbg!(fdev, dyndbg repro dev: {}\n", read_status(&reads, &formats));

reads and formats are two counters.

With dynamic debug disabled, both macros produce:

dyndbg repro pr: args=1 fmt=0
dyndbg repro dev: args=1 fmt=0

which shows the params are evaluated unexpectedly.

My solution was moving the fmt!() into dynamic_func_call()!

I attached the testing code as well. Feel free to try it.

quoted

- The dynamic-debug prefix flags remain supported. (I use the C
version of dynamic debug to support e.g. +m, +l and _t)

Absolutely, this is a bug in my v1. It is fixed in v2.

quoted

Could you share your pending encapsulation/Opaque and static-branch
wip patches? We can then work out how they fit together, incorporate
Alice's review feedback, and preserve attribution for Andrew's work.

Here:

https://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git/log/?h=b4/rust-dyndbg

quoted

Thanks,
Zhi.

quoted

Hi Alexandre,

On 2026-10-20 22:14:12+0900, Alexandre Courbot wrote:

quoted

On Sun Oct 11, 2026 at 9:52 PM JST, Thomas Weißschuh wrote:  

quoted

Add the Rust infrastructure to integrate with the dynamic
debug infrastructure.

Static keys are not used for now, as the full bindings are
missing for those. A follow-up series will add that.
Also custom classes are not supported yet, but could be added
on top.

Patches 1-4: Generic Rust preparation patches.
Patches 5-7: C dynamic debug preparation patches.
Patches 8: Rust Dynamic debug infrastructure.
Patches 9-11: Rust Dynamic debug enablement.  

Were you aware of this series [1]?  

I was was told about the original work from Andrew back at
Kangrejos. However I was unable to find it on LKML and it was not
clear how far along that series has come along. The posting of
Zhi's v3 only happened after I started on my variant, and I did
not see it until you mentioned it. So my development is
completely independent from Andrew's and Zhi's.

quoted

There seems to be quite a bit of overlap.  

Indeed. I see pros for both serieses:

Mine:
* No FFI in the fastpath.
* No need for RUST_MODNAME.
* Use of Bounded.
* Tests for the flag encoding.
* modname!() as function name.
  (As discussed with Benno and Gary and LPC)
* Better encapsulation of 'struct Descriptor' (partially not yet
posted)
* Use of Opaque<> to wrap bindings::_ddebug (not yet posted).
* Use of !cv() (not yet posted).

Andrew/Zhi:
* Better docs.
* Static branch support.
  * static_branch_likely!() support is missing however.
  * I also have follow-up patches to enable
static_branch_likely!().
* host doctest support.

I am perfectly fine with merging both serieses.


Thomas

quoted

[1]
https://lore.kernel.org/all/20261001145940.1077801-1-zhiw@nvidia.com/ (local)