so as a proof of concept, Ive converted drm to use dynamic-debug drm has ~dozen categories of debug messages, mapped to bits in drm.debug, aka /sys/module/drm/parameters/debug these bits are checked at runtime by drm_debug_enabled() to do drm debug printing. my patchset updates users of drm_debug_enabled() to call pr_debug instead, avoiding lots of bit-checking. it maps bits of drm.debug using dynamic_debug_exec_queries(), a recently exported function to support this sort of thing. you can see it here https://github.com/jimc/linux/tree/dd-drm A narrower interface than dynamic_debug_exec_queries() is possible: +static char *format_prefix_classes[] = { + "gvt: cmd: ", + "gvt: core: ", + "gvt: dpy: ", + "gvt: el: ", + "gvt: irq: ", + "gvt: mm: ", + "gvt: mmio: ", + "gvt: render: ", + "gvt: sched: " +}; +static const struct kernel_param_ops param_ops_dyndbg = { + .set = param_set_dyndbg, + .get = param_get_dyndbg, +}; + +#define info_ln(hexi, prefix) "\n\t0x" __stringify(hexi) "\t" prefix + +MODULE_PARM_DESC(debug_gvt, " gvt debug categories:" + info_ln(1, "gvt: cmd:") + info_ln(2, "gvt: core:") + info_ln(4, "gvt: dpy:") + info_ln(8, "gvt: el:") + info_ln(10, "gvt: irq:") + info_ln(20, "gvt: mm:") + info_ln(40, "gvt: mmio:") + info_ln(80, "gvt: render:") + info_ln(100, "gvt: sched:")); + +module_param_cb(debug_gvt, ¶m_ops_dyndbg, &__gvt_debug, 0644); this is useful in that it shows up in modinfo output but there could be better presentation, maybe /sys/module/drm/parameters/debug.help param_set_dyndbg could be moved into dynamic-debug proper, instead of reimplemented everywhere debug bits control debug prints (currently drm, maybe others, could be i915/gvt) the point is that this integer parameter maps consecutive bits to "classes" named in an input vector. these "classes" are just format ^prefix queries clearly we shouldnt need the 1,2,4... whats a good interface design for this module-param-bitmap ?