On Mon, Mar 24, 2025 at 9:07 AM Louis Chauvet <louis.chau...@bootlin.com> wrote:
>
trimming
> >>> + __section("__dyndbg_class_users") _uname = { \
> >>> + .mod_name = KBUILD_MODNAME, \
> >>> + .map = &(_var), \
> >>> + }
> >>> +
> >>
> >> I'm not sure I understand properly how __section works, but can we use
> >> multiple DYNDBG_CLASSMAP_USE in one module? Can we also use
> >> DYNDBG_CLASSMAP_DEFINE while also importing an other classmap
> >> DYNDBG_CLASSMAP_USE?
> >>
> >
> > Yes, its supposed to work that way.
> >
> > I havent tested that specific scenario (yet), but
> > a _USEr module, like test-dynamic-debug-submod,
> > could also _DEFINE its own, as long as it honors
> > the class-id mapping it is using and therefore sharing.
> > The on-modprobe conflict check should catch this condition.
> >
> > And __section (ISTM) accumulates entries, typically static struct var
> > initializations.
> > AFAICT, scanning the sections is how these { scoped statics } are
> > often reachable.
> >
> > For example, dd's _METADATA_ builds a { static _ddebug } for every pr_debug.
> > They all go into the __dyndbg section (renamed with _descriptors suffix
> > soon),
> > in the order their respective definer objects are linked.
> >
> > include/asm-generic/vmlinux.lds.h then places the __dyndbg_* sections
> > into DATA, along with lots of other freight, for the various
> > mechanisms they serve.
> >
> >
> >
> >
> >> If not, does it make sense to allow it (for example MFD devices can
> >> touch multiple subsystems)?
> >
> > We have another use case !
> > Do you know your way around that case ?
> >
>
> No, I don't have other use cases, I was just thinking about possible
> scenarios of the "include multiple classmap".
>
> So, happy to konw it is not an issue with the section, but do I
> understand properly the code (completly hypotetical example): if drm.ko
> defines classes 0..10 and spi.ko defines classes 0..4, it means
> driver.ko can't use both classmap? (I don't have such use-case, and
> maybe this use-case does not exists!)
>
It sounds realistic on the face of it, so lets break it down:
1st off, drm drivers/helpers are full dependents on (core) drm.ko.
they are the "subsystem" users I considered.
This dependence is "+1" by _USE ref'g the exported DEFINE product.
If that dependence doesn't suit a situation, it doesn't quite fit.
The dependence dictates module-load order, amongst other things.
So it follows that spi.ko would never be a dependent module on drm.ko,
if there is a relationship, DRM would use spi, and whatever classes it defines.
Suppose spi.ko DEFINEd a classmap: with ENDPOINT, TRANSPORT, BULK
categories of pr_debugs, those classes would need to map to different class-ids
than DRM_UT_<*>, cuz the callsites only have the classids, not the
name-->id mapping.
if both DRM_UT_CORE and ENPOINT had class-id = 0,
then both these commands would alter the same set of pr-debugs
echo class DRM_UT_CORE +p > /proc/dynamic-debug/control
echo class SPI_ENDPOINT -p > /proc/dynamic-debug/control
Thats not as troublesome as it might seem:
DRM's DRM_UT_<*> vals are only exposed to userspace
by the existence of : /sys/module/drm/parameter/debug,
cuz it exposes the bit values in >debug input.
and this already changed DRM_UT_<*> vals wo anybody caring.
0406faf25fb1 drm_print: condense enum drm_debug_category
DYNAMIC-DEBUG-CLASSMAP-DEFINE() has _base arg,
which offsets the natural/obvious 0..N range to allow sharing of 0..62 range.
The outer edge of inconvenience in coordinating class-id reservations
would be N providers and M consumers. ATM, N=M=1.
Say DRM used 2 modules defining classmaps: spi (as discussed),
and (pure wag) gpu_engine.
Those 2 modules dont really have any other connection, but would have
to coordinate
(but maybe gpu_engine needs spi to control its cooling, and would want
to anyway)
DRM (or any classmap-definer/user) is also free to define a 2nd "category"
enum to separate the user facing aspects of DRM_UT_*
from its name->ID mapping (very internal)
Also: "classnames" are a public-namespace; theres nothing
to stop a module from defining their own version of "DRM_UT_CORE",
and getting their pr_debugs enabled/disabled along with all of DRMs callsites.
Such a use-case would be obvious in review, and would want some justification.
WAG: a _base arg to the _USE() macro could specify a local user offset.
Theres a saying: if youre explaining, youre losing.
How'd I do ?
> The only solution I see is to add more stuff in the _ddebug structure
> (for example a "classmap identifier"). But for now, the current user
> will be DRM, so we don't really need to fix this issue right now.
>
> I just found a possible user for dyndbg classes [1], it seems to
> implement something similar.
>
> [1]:https://elixir.bootlin.com/linux/v6.13.7/source/drivers/block/drbd/drbd_polymorph_printk.h
>
thats a pretty impressive stack of macros.
I like the componentry and assembly
One thing that puts it out of scope is its use of KERN_EMERG, CRIT etc.
dyndbg is just KERN_DEBUG
Also those #undef *DYNAMIC_DEBUG*
explicitly unwire dyndbg apparatus, and plug into __dynamic_pr_debug directly.
Making it an interesting case.
> > Note that DEFINEr & USEr calls set up linkage dependencies,
> > As long as these are consistent with other module deps,
> > it should work.
> >
> >
> >>
