kernel module parameter API ala drm.debug

[jim.cromie at gmail.com]

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, &param_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 ?