On Tue, 20 Oct 2026 23:36:56 +0200
Thomas Weißschuh <linux@weissschuh.net> wrote:

> On 2026-10-20 21:25:42+0300, Zhi Wang wrote:
> > On Tue, 20 Oct 2026 19:30:33 +0200
> > Thomas Weißschuh <linux@weissschuh.net> wrote:
> > 
> > > +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.
> 
> > 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.

> > - 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.

> > - 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.
> 
> > 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
> 
> > Thanks,
> > Zhi.
> > 
> > > Hi Alexandre,
> > > 
> > > On 2026-10-20 22:14:12+0900, Alexandre Courbot wrote:
> > > > On Sun Oct 11, 2026 at 9:52 PM JST, Thomas Weißschuh wrote:  
> > > > > 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.
> > > 
> > > > 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
> > > 
> > > > [1]
> > > > https://lore.kernel.org/all/20261001145940.1077801-1-zhiw@nvidia.com/
> > > >  
> > 
>