All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Cromie <jim.cromie@gmail.com>
To: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, jbaron@akamai.com,
	gregkh@linuxfoundation.org, daniel.vetter@ffwll.ch,
	seanpaul@chromium.org, robdclark@gmail.com
Cc: Jim Cromie <jim.cromie@gmail.com>
Subject: [Intel-gfx] [PATCH v4 12/41] dyndbg: add DECLARE_DYNDBG_CLASSMAP
Date: Wed, 20 Jul 2022 09:32:04 -0600	[thread overview]
Message-ID: <20220720153233.144129-13-jim.cromie@gmail.com> (raw)
In-Reply-To: <20220720153233.144129-1-jim.cromie@gmail.com>

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

DD_CLASS_TYPE_DISJOINT: classes are separate, one per bit.
   expecting hex input. basis for others.

DD_CLASS_TYPE_SYMBOLIC: input is a CSV of [+-]CLASS_NAMES,
   classes are independent, like DISJOINT

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_LEVELS: input is a CSV of [+-]CLASS_NAMES,
   names like: ERR,WARNING,NOTICE,INFO,DEBUG
   avoiding EMERG,ALERT,CRIT,ERR - no point.

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)
 
-- 
2.36.1


WARNING: multiple messages have this Message-ID (diff)
From: Jim Cromie <jim.cromie@gmail.com>
To: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, jbaron@akamai.com,
	gregkh@linuxfoundation.org, daniel.vetter@ffwll.ch,
	seanpaul@chromium.org, robdclark@gmail.com
Subject: [PATCH v4 12/41] dyndbg: add DECLARE_DYNDBG_CLASSMAP
Date: Wed, 20 Jul 2022 09:32:04 -0600	[thread overview]
Message-ID: <20220720153233.144129-13-jim.cromie@gmail.com> (raw)
In-Reply-To: <20220720153233.144129-1-jim.cromie@gmail.com>

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

DD_CLASS_TYPE_DISJOINT: classes are separate, one per bit.
   expecting hex input. basis for others.

DD_CLASS_TYPE_SYMBOLIC: input is a CSV of [+-]CLASS_NAMES,
   classes are independent, like DISJOINT

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_LEVELS: input is a CSV of [+-]CLASS_NAMES,
   names like: ERR,WARNING,NOTICE,INFO,DEBUG
   avoiding EMERG,ALERT,CRIT,ERR - no point.

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)
 
-- 
2.36.1


WARNING: multiple messages have this Message-ID (diff)
From: Jim Cromie <jim.cromie@gmail.com>
To: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, jbaron@akamai.com,
	gregkh@linuxfoundation.org, daniel.vetter@ffwll.ch,
	seanpaul@chromium.org, robdclark@gmail.com
Cc: Jim Cromie <jim.cromie@gmail.com>
Subject: [PATCH v4 12/41] dyndbg: add DECLARE_DYNDBG_CLASSMAP
Date: Wed, 20 Jul 2022 09:32:04 -0600	[thread overview]
Message-ID: <20220720153233.144129-13-jim.cromie@gmail.com> (raw)
In-Reply-To: <20220720153233.144129-1-jim.cromie@gmail.com>

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

DD_CLASS_TYPE_DISJOINT: classes are separate, one per bit.
   expecting hex input. basis for others.

DD_CLASS_TYPE_SYMBOLIC: input is a CSV of [+-]CLASS_NAMES,
   classes are independent, like DISJOINT

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_LEVELS: input is a CSV of [+-]CLASS_NAMES,
   names like: ERR,WARNING,NOTICE,INFO,DEBUG
   avoiding EMERG,ALERT,CRIT,ERR - no point.

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)
 
-- 
2.36.1


  parent reply	other threads:[~2022-07-20 15:33 UTC|newest]

Thread overview: 156+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 15:31 [Intel-gfx] [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm Jim Cromie
2022-07-20 15:31 ` Jim Cromie
2022-07-20 15:31 ` Jim Cromie
2022-07-20 15:31 ` [Intel-gfx] [PATCH v4 01/41] dyndbg: fix static_branch manipulation Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31 ` [PATCH v4 02/41] dyndbg: fix module.dyndbg handling Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31   ` [Intel-gfx] " 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   ` Jim Cromie
2022-07-20 15:31   ` [Intel-gfx] " 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   ` Jim Cromie
2022-07-20 15:31   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:31 ` [Intel-gfx] [PATCH v4 05/41] dyndbg: reverse module.callsite " Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31 ` [Intel-gfx] [PATCH v4 06/41] dyndbg: use ESCAPE_SPACE for " Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31 ` [Intel-gfx] [PATCH v4 07/41] dyndbg: let query-modname override actual module name Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:31   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 08/41] dyndbg: add test_dynamic_debug module Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 09/41] dyndbg: drop EXPORTed dynamic_debug_exec_queries Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 10/41] dyndbg: add class_id to pr_debug callsites Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 11/41] dyndbg: add __pr_debug_cls for testing Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` Jim Cromie [this message]
2022-07-20 15:32   ` [PATCH v4 12/41] dyndbg: add DECLARE_DYNDBG_CLASSMAP Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-22 20:23   ` Jason Baron
2022-07-22 20:23     ` [Intel-gfx] " Jason Baron
2022-07-22 23:23     ` jim.cromie
2022-07-22 23:23       ` jim.cromie
2022-07-22 23:23       ` [Intel-gfx] " jim.cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 13/41] kernel/module: add __dyndbg_classes section Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 14/41] dyndbg: add ddebug_attach_module_classes Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 16/41] dyndbg: add drm.debug style bitmap support Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-22 20:33   ` Jason Baron
2022-07-22 20:33     ` [Intel-gfx] " Jason Baron
2022-07-28 21:25     ` jim.cromie
2022-07-28 21:25       ` jim.cromie
2022-07-28 21:25       ` [Intel-gfx] " 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " 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   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32   ` 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 24/41] drm-print: add drm_dbg_driver to improve namespace symmetry Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 25/41] drm-print: include dyndbg header indirectly Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 26/41] drm_print: refine drm_debug_enabled for jump-label Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 27/41] drm_print: prefer bare printk KERN_DEBUG on generic fn Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 28/41] drm_print: add _ddebug descriptor to drm_*dbg prototypes Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 29/41] nouveau: change nvkm_debug/trace to use dev_dbg POC Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32 ` [PATCH v4 31/41] dyndbg: add _DPRINTK_FLAGS_ENABLED Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 32/41] dyndbg: add _DPRINTK_FLAGS_TRACE Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 33/41] dyndbg: add write-events-to-tracefs code Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 34/41] dyndbg: add 2 trace-events: drm_{, dev}debug 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   ` 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   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32   ` 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   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 37/41] nouveau: adapt NV_DEBUG, NV_ATOMIC to use DRM.debug Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 38/41] nouveau-dyndbg: alter DEBUG, TRACE, SPAM levels to use dyndbg Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [Intel-gfx] [PATCH v4 39/41] nouveau-dbg: add 2 verbose-classmaps for CLI, SUBDEV Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32 ` [PATCH v4 40/41] nouveau-dbg: fixup lost prdbgs Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " Jim Cromie
2022-07-20 15:32 ` [PATCH v4 41/41] nouveau-dyndbg: wip subdev refine, breaks on use Jim Cromie
2022-07-20 15:32   ` Jim Cromie
2022-07-20 15:32   ` [Intel-gfx] " Jim Cromie
2022-07-20 17:06 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for DYNDBG: opt-in class'd debug for modules, use in drm. (rev2) Patchwork
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 19:56   ` [Intel-gfx] " jim.cromie
2022-08-03 20:13   ` Jason Baron
2022-08-03 20:13     ` [Intel-gfx] " Jason Baron
2022-08-11 16:52     ` Daniel Vetter
2022-08-11 16:52       ` Daniel Vetter
2022-08-11 16:52       ` [Intel-gfx] " Daniel Vetter
2022-08-12  6:03       ` Greg KH
2022-08-12  6:03         ` Greg KH
2022-08-12  6:03         ` [Intel-gfx] " Greg KH
2022-09-06 19:18         ` Daniel Vetter
2022-09-06 19:18           ` Daniel Vetter
2022-09-06 19:18           ` [Intel-gfx] " Daniel Vetter
2022-09-07  5:47           ` Greg KH
2022-09-07  5:47             ` Greg KH
2022-09-07  5:47             ` [Intel-gfx] " Greg KH
2022-09-07  6:08             ` Daniel Vetter
2022-09-07  6:08               ` Daniel Vetter
2022-09-07  6:08               ` [Intel-gfx] " 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=20220720153233.144129-13-jim.cromie@gmail.com \
    --to=jim.cromie@gmail.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=jbaron@akamai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.