From: Jason Baron <jbaron@akamai.com>
To: Jim Cromie <jim.cromie@gmail.com>,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, gregkh@linuxfoundation.org,
daniel.vetter@ffwll.ch, seanpaul@chromium.org,
robdclark@gmail.com
Subject: Re: [PATCH v4 12/41] dyndbg: add DECLARE_DYNDBG_CLASSMAP
Date: Fri, 22 Jul 2022 16:23:40 -0400 [thread overview]
Message-ID: <9e34b45f-c091-223b-58ac-107cfbebd92c@akamai.com> (raw)
In-Reply-To: <20220720153233.144129-13-jim.cromie@gmail.com>
On 7/20/22 11:32, Jim Cromie wrote:
> DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this
> opt-in authorizes dyndbg to allow enabling of prdbgs by their class:
>
> :#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
>
> This is just the setup; following commits deliver.
>
> The macro declares and initializes a static struct ddebug_class_map:
>
> - maps approved class-names to class_ids used in module,
> by array order. forex: DRM_UT_*
> - class-name vals allow validation of "class FOO" queries
> using macro is opt-in
> - enum class_map_type - determines interface, behavior
>
> Each module has its own .class_id space, and only known class-names
> will be authorized for a manipulation. Only DRM stuff should know this:
>
> :#> echo class DRM_UT_CORE +p > control # across all modules
>
> pr_debugs (with default class_id) are still controllable as before.
>
> DECLARE_DYNDBG_CLASSMAP(_var, _maptype, _base, classes...) is::
>
> _var: name of the static struct var. user passes to module_param_cb()
> if they want a sysfs node. (ive only done it this way).
>
> _maptype: this is hard-coded to DD_CLASS_TYPE_DISJOINT for now.
>
> _base: usually 0, it allows splitting 31 classes into subranges, so
> that multiple classes / sysfs-nodes can share the module's
> class-id space.
>
> classes: list of class_name strings, these are mapped to class-ids
> starting at _base. This class-names list must have a
> corresponding ENUM, with SYMBOLS that match the literals,
> and 1st enum val = _base.
>
> enum class_map_type has 4 values, on 2 factors::
>
> - classes are disjoint/independent vs relative/x<y/verbosity.
> disjoint is basis, verbosity by overlay.
>
> - input NUMBERS vs [+-]CLASS_NAMES
> uints, ideally hex. vs +DRM_UT_CORE,-DRM_UT_KMS
>
Could the naming here directly reflect the 2 factors? At least for me
I think it's more readable. So something like:
> DD_CLASS_TYPE_DISJOINT: classes are separate, one per bit.
> expecting hex input. basis for others.
DD_CLASS_TYPE_DISJOINT_NUM
>
> DD_CLASS_TYPE_SYMBOLIC: input is a CSV of [+-]CLASS_NAMES,
> classes are independent, like DISJOINT
>
DD_CLASS_TYPE_DISJOINT_NAME
> DD_CLASS_TYPE_VERBOSE: input is numeric level, 0-N.
> 0 implies silence. use printk to break that.
> relative levels applied on bitmaps.
>
DD_CLASS_TYPE_LEVEL_NUM
> DD_CLASS_TYPE_LEVELS: input is a CSV of [+-]CLASS_NAMES,
> names like: ERR,WARNING,NOTICE,INFO,DEBUG
> avoiding EMERG,ALERT,CRIT,ERR - no point.
>
DD_CLASS_TYPE_LEVEL_NAME
> NOTES:
>
> The macro places the initialized struct ddebug_class_map into the
> __dyndbg_classes section. That draws a 'orphan' warning which we
> handle in next commit. The struct attributes are necessary:
> __aligned(8) stopped null-ptr derefs (why?), __used is needed by drm
> drivers, which declare class-maps, but don't also declare a
> sysfs-param, and thus dont ref the classmap; __used insures that the
> linkage is made, then the class-map is found at load-time.
>
> While its possible to handle both NAMES and NUMBERS in the same
> sys-interface, there is ambiguity to avoid, by disallowing them
> together. Later, if ambiguities are resolved, 2 new enums can permit
> both inputs, on verbose & independent types separately, and authors
> can select the interface they like.
>
> RFC:
>
> My plan is to implement LEVELS in the callbacks, outside of
> ddebug_exec_query(), which for simplicity will treat the CLASSES in
> the map as disjoint. This should handle most situations.
>
> The callbacks can see map-type, and apply ++/-- loops (or bitops) to
> force the relative meanings across the class-bitmap.
>
> That leaves 2 issues:
>
> 1. doing LEVELs in callbacks means that the native >control interface
> doesn't enforce the LEVELS relationship, so you could confusingly have
> V3 enabled, but V1 disabled. OTOH, the control iface already allows
> infinite variety in the underlying callsites, despite the veneer of
> uniformity suggested by the bitmap overlay, and LEVELS over that.
>
> 2. All dyndbg >control reduces to a query/command, includes +/-, which
> is at-root a kernel patching operation with +/- semantics. And the
> symbolic sys-node handling exposes it to the user:
>
> Consider whether these are/should-be 'exactly' the same:
>
> # force both 2 "half-duplex" relations
> echo +V3,-V4 > /sys/module/test_dynamic_debug/p_VX
>
> # should these both do the same ?
> echo +V3 > /sys/module/test_dynamic_debug/p_VX
> echo -V4 > /sys/module/test_dynamic_debug/p_VX
>
> IOW, half relations are suggested by the +/-, and enum control of
> individual behaviors leaves some room for this, especially wrt
> handling [+-]SYMBOLIC inputs from the user.
>
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
> include/linux/dynamic_debug.h | 55 +++++++++++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
>
> diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
> index 0f7ad6cecf05..84e97cd0e8c4 100644
> --- a/include/linux/dynamic_debug.h
> +++ b/include/linux/dynamic_debug.h
> @@ -56,7 +56,62 @@ struct _ddebug {
> #endif
> } __attribute__((aligned(8)));
>
> +enum class_map_type {
> + DD_CLASS_TYPE_DISJOINT,
> + /**
> + * DD_CLASS_TYPE_DISJOINT: classes are independent, one per bit.
> + * expecting hex input. basis for others.
> + */
> + DD_CLASS_TYPE_VERBOSE,
> + /**
> + * DD_CLASS_TYPE_VERBOSE: input is numeric level, 0-N.
> + * 0 should be silent, use printk to break that.
> + * (x<y) relationship on bitpos
> + */
> + DD_CLASS_TYPE_SYMBOLIC,
> + /**
> + * DD_CLASS_TYPE_SYMBOLIC: input is a CSV of [+-]CLASS_NAMES,
> + * classes are independent, like DISJOINT
> + */
> + DD_CLASS_TYPE_LEVELS,
> + /**
> + * DD_CLASS_TYPE_LEVELS: input is a CSV of [+-]CLASS_NAMES,
> + * intended for names like: ERR,WARNING,NOTICE,INFO,DEBUG
> + * avoid ? EMERG,ALERT,CRIT,ERR,WARNING ??
> + */
> +};
> +
> +struct ddebug_class_map {
> + struct list_head link;
> + struct module *mod;
> + const char *mod_name; /* needed for builtins */
> + const char **class_names;
> + const int length;
> + const int base; /* index of 1st .class_id, allows split/shared space */
> + enum class_map_type map_type;
> +};
> +
> +/**
> + * DECLARE_DYNDBG_CLASSMAP - declare classnames known by a module
> + * @_var: a struct ddebug_class_map, passed to module_param_cb
> + * @_type: enum class_map_type, chooses bits/verbose, numeric/symbolic
> + * @_base: offset of 1st class-name. splits .class_id space
> + * @classes: class-names used to control class'd prdbgs
> + */
> +#define DECLARE_DYNDBG_CLASSMAP(_var, _maptype, _base, ...) \
> + static const char *_var##_classnames[] = { __VA_ARGS__ }; \
> + static struct ddebug_class_map __aligned(8) __used \
> + __section("__dyndbg_classes") _var = { \
> + .mod = THIS_MODULE, \
> + .mod_name = KBUILD_MODNAME, \
> + .base = _base, \
> + .map_type = _maptype, \
> + .length = NUM_TYPE_ARGS(char*, __VA_ARGS__), \
> + .class_names = _var##_classnames, \
> + }
>
> +#define NUM_TYPE_ARGS(eltype, ...) \
> + (sizeof((eltype[]) {__VA_ARGS__}) / sizeof(eltype))
>
> #if defined(CONFIG_DYNAMIC_DEBUG_CORE)
>
next prev parent reply other threads:[~2022-07-22 21:09 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 15:31 [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm Jim Cromie
2022-07-20 15:31 ` [PATCH v4 01/41] dyndbg: fix static_branch manipulation Jim Cromie
2022-07-20 15:31 ` [PATCH v4 02/41] dyndbg: fix module.dyndbg handling Jim Cromie
2022-07-20 15:31 ` [PATCH v4 03/41] dyndbg: show both old and new in change-info Jim Cromie
2022-07-20 15:31 ` [PATCH v4 04/41] dyndbg: reverse module walk in cat control Jim Cromie
2022-07-20 15:31 ` [PATCH v4 05/41] dyndbg: reverse module.callsite " Jim Cromie
2022-07-20 15:31 ` [PATCH v4 06/41] dyndbg: use ESCAPE_SPACE for " Jim Cromie
2022-07-20 15:31 ` [PATCH v4 07/41] dyndbg: let query-modname override actual module name Jim Cromie
2022-07-20 15:32 ` [PATCH v4 08/41] dyndbg: add test_dynamic_debug module Jim Cromie
2022-07-20 15:32 ` [PATCH v4 09/41] dyndbg: drop EXPORTed dynamic_debug_exec_queries Jim Cromie
2022-07-20 15:32 ` [PATCH v4 10/41] dyndbg: add class_id to pr_debug callsites Jim Cromie
2022-07-20 15:32 ` [PATCH v4 11/41] dyndbg: add __pr_debug_cls for testing Jim Cromie
2022-07-20 15:32 ` [PATCH v4 12/41] dyndbg: add DECLARE_DYNDBG_CLASSMAP Jim Cromie
2022-07-22 20:23 ` Jason Baron [this message]
2022-07-22 23:23 ` jim.cromie
2022-07-20 15:32 ` [PATCH v4 13/41] kernel/module: add __dyndbg_classes section Jim Cromie
2022-07-20 15:32 ` [PATCH v4 14/41] dyndbg: add ddebug_attach_module_classes Jim Cromie
2022-07-20 15:32 ` [PATCH v4 15/41] dyndbg: validate class FOO by checking with module Jim Cromie
2022-07-20 15:32 ` [PATCH v4 16/41] dyndbg: add drm.debug style bitmap support Jim Cromie
2022-07-22 20:33 ` Jason Baron
2022-07-28 21:25 ` jim.cromie
2022-07-20 15:32 ` [PATCH v4 17/41] dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodes Jim Cromie
2022-07-20 15:32 ` [PATCH v4 18/41] doc-dyndbg: describe "class CLASS_NAME" query support Jim Cromie
2022-07-20 15:32 ` [PATCH v4 19/41] doc-dyndbg: edit dynamic-debug-howto for brevity, audience Jim Cromie
2022-07-20 15:32 ` [PATCH v4 20/41] drm_print: condense enum drm_debug_category Jim Cromie
2022-07-20 15:32 ` [PATCH v4 21/41] drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers Jim Cromie
2022-07-20 15:32 ` [PATCH v4 22/41] drm_print: interpose drm_*dbg with forwarding macros Jim Cromie
2022-07-20 15:32 ` [PATCH v4 23/41] drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro Jim Cromie
2022-07-20 15:32 ` [PATCH v4 24/41] drm-print: add drm_dbg_driver to improve namespace symmetry Jim Cromie
2022-07-20 15:32 ` [PATCH v4 25/41] drm-print: include dyndbg header indirectly Jim Cromie
2022-07-20 15:32 ` [PATCH v4 26/41] drm_print: refine drm_debug_enabled for jump-label Jim Cromie
2022-07-20 15:32 ` [PATCH v4 27/41] drm_print: prefer bare printk KERN_DEBUG on generic fn Jim Cromie
2022-07-20 15:32 ` [PATCH v4 28/41] drm_print: add _ddebug descriptor to drm_*dbg prototypes Jim Cromie
2022-07-20 15:32 ` [PATCH v4 29/41] nouveau: change nvkm_debug/trace to use dev_dbg POC Jim Cromie
2022-07-20 15:32 ` [PATCH v4 30/41] tracing/events: Add __vstring() and __assign_vstr() helper macros Jim Cromie
2022-07-20 15:32 ` [PATCH v4 31/41] dyndbg: add _DPRINTK_FLAGS_ENABLED Jim Cromie
2022-07-20 15:32 ` [PATCH v4 32/41] dyndbg: add _DPRINTK_FLAGS_TRACE Jim Cromie
2022-07-20 15:32 ` [PATCH v4 33/41] dyndbg: add write-events-to-tracefs code Jim Cromie
2022-07-20 15:32 ` [PATCH v4 34/41] dyndbg: add 2 trace-events: drm_{,dev}debug Jim Cromie
2022-07-20 15:32 ` [PATCH v4 35/41] dyndbg: add 2 more trace-events: pr_debug, dev_dbg Jim Cromie
2022-07-20 15:32 ` [PATCH v4 36/41] dyndbg/drm: POC add tracebits sysfs-knob Jim Cromie
2022-07-20 15:32 ` [PATCH v4 37/41] nouveau: adapt NV_DEBUG, NV_ATOMIC to use DRM.debug Jim Cromie
2022-07-20 15:32 ` [PATCH v4 38/41] nouveau-dyndbg: alter DEBUG, TRACE, SPAM levels to use dyndbg Jim Cromie
2022-07-20 15:32 ` [PATCH v4 39/41] nouveau-dbg: add 2 verbose-classmaps for CLI, SUBDEV Jim Cromie
2022-07-20 15:32 ` [PATCH v4 40/41] nouveau-dbg: fixup lost prdbgs Jim Cromie
2022-07-20 15:32 ` [PATCH v4 41/41] nouveau-dyndbg: wip subdev refine, breaks on use Jim Cromie
2022-08-03 19:56 ` [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm jim.cromie
2022-08-03 20:13 ` Jason Baron
2022-08-11 16:52 ` Daniel Vetter
2022-08-12 6:03 ` Greg KH
2022-09-06 19:18 ` Daniel Vetter
2022-09-07 5:47 ` Greg KH
2022-09-07 6:08 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e34b45f-c091-223b-58ac-107cfbebd92c@akamai.com \
--to=jbaron@akamai.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jim.cromie@gmail.com \
--cc=robdclark@gmail.com \
--cc=seanpaul@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).