On 2026-10-20 21:25:42+0300, Zhi Wang wrote:
> On Tue, 20 Oct 2026 19:30:33 +0200
> Thomas Weißschuh <[email protected]> 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'?

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

> - 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/[email protected]/
> > >  
> 

Reply via email to