From: Jim Cromie <jim.cromie@gmail.com>
To: daniel.vetter@ffwll.ch, daniel@ffwll.ch, jbaron@akamai.com,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org
Cc: jani.nikula@intel.com, linux@rasmusvillemoes.dk,
Jim Cromie <jim.cromie@gmail.com>,
robdclark@gmail.com, seanpaul@chromium.org, joe@perches.com,
ville.syrjala@linux.intel.com
Subject: [PATCH v5 02/22] test-dyndbg: fixup CLASSMAP usage error
Date: Tue, 1 Aug 2023 11:02:34 -0600 [thread overview]
Message-ID: <20230801170255.163237-3-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230801170255.163237-1-jim.cromie@gmail.com>
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. I intentionally coded in an error, but
forgot to verify its detection and remove it.
RFC:
This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone. As noted in test-mod comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__. Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.
[1] name changes later to DYNDBG_CLASSMAP_DEFINE
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.41.0
WARNING: multiple messages have this Message-ID (diff)
From: Jim Cromie <jim.cromie@gmail.com>
To: daniel.vetter@ffwll.ch, daniel@ffwll.ch, jbaron@akamai.com,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org
Cc: jani.nikula@intel.com, linux@rasmusvillemoes.dk,
Jim Cromie <jim.cromie@gmail.com>,
seanpaul@chromium.org, joe@perches.com
Subject: [Intel-gfx] [PATCH v5 02/22] test-dyndbg: fixup CLASSMAP usage error
Date: Tue, 1 Aug 2023 11:02:34 -0600 [thread overview]
Message-ID: <20230801170255.163237-3-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230801170255.163237-1-jim.cromie@gmail.com>
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. I intentionally coded in an error, but
forgot to verify its detection and remove it.
RFC:
This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone. As noted in test-mod comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__. Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.
[1] name changes later to DYNDBG_CLASSMAP_DEFINE
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.41.0
WARNING: multiple messages have this Message-ID (diff)
From: Jim Cromie <jim.cromie@gmail.com>
To: daniel.vetter@ffwll.ch, daniel@ffwll.ch, jbaron@akamai.com,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org
Cc: jani.nikula@intel.com, linux@rasmusvillemoes.dk,
seanpaul@chromium.org, joe@perches.com
Subject: [PATCH v5 02/22] test-dyndbg: fixup CLASSMAP usage error
Date: Tue, 1 Aug 2023 11:02:34 -0600 [thread overview]
Message-ID: <20230801170255.163237-3-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230801170255.163237-1-jim.cromie@gmail.com>
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. I intentionally coded in an error, but
forgot to verify its detection and remove it.
RFC:
This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone. As noted in test-mod comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__. Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.
[1] name changes later to DYNDBG_CLASSMAP_DEFINE
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.41.0
WARNING: multiple messages have this Message-ID (diff)
From: Jim Cromie <jim.cromie@gmail.com>
To: daniel.vetter@ffwll.ch, daniel@ffwll.ch, jbaron@akamai.com,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org
Cc: linux@rasmusvillemoes.dk, joe@perches.com, jani.nikula@intel.com,
ville.syrjala@linux.intel.com, seanpaul@chromium.org,
robdclark@gmail.com, Jim Cromie <jim.cromie@gmail.com>
Subject: [PATCH v5 02/22] test-dyndbg: fixup CLASSMAP usage error
Date: Tue, 1 Aug 2023 11:02:34 -0600 [thread overview]
Message-ID: <20230801170255.163237-3-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230801170255.163237-1-jim.cromie@gmail.com>
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. I intentionally coded in an error, but
forgot to verify its detection and remove it.
RFC:
This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone. As noted in test-mod comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__. Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.
[1] name changes later to DYNDBG_CLASSMAP_DEFINE
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.41.0
next prev parent reply other threads:[~2023-08-01 17:03 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 17:02 [PATCH v5 00/22] fix DRM_USE_DYNAMIC_DEBUG regression Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 01/22] drm: use correct ccflags-y syntax Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` Jim Cromie [this message]
2023-08-01 17:02 ` [PATCH v5 02/22] test-dyndbg: fixup CLASSMAP usage error Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 03/22] dyndbg: make ddebug_class_param union members same size Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 04/22] dyndbg: replace classmap list with a vector Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 05/22] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 06/22] dyndbg: split param_set_dyndbg_classes to module/wrapper fns Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 07/22] dyndbg: drop NUM_TYPE_ARRAY Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 08/22] dyndbg: reduce verbose/debug clutter Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 09/22] dyndbg: silence debugs with no-change updates Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 10/22] dyndbg: tighten ddebug_class_name() 1st arg type Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 11/22] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 12/22] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 13/22] checkpatch: file-scoped extern special case for linker-symbol Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 13/22] checkpatch: special case for file-scoped extern linker-symbol Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 14/22] dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 15/22] dyndbg: add for_each_boxed_vector Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 16/22] dyndbg: refactor ddebug_classparam_clamp_input Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 17/22] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 18/22] dyndbg-test: build it with just CONFIG_DYNAMIC_DEBUG_CORE Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 19/22] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-03 7:13 ` kernel test robot
2023-08-03 7:13 ` kernel test robot
2023-08-03 7:13 ` kernel test robot
2023-08-03 7:13 ` kernel test robot
2023-08-03 20:04 ` jim.cromie
2023-08-03 20:04 ` jim.cromie
2023-08-03 20:04 ` jim.cromie
2023-08-03 20:04 ` jim.cromie
2023-08-03 20:21 ` jim.cromie
2023-08-03 20:21 ` jim.cromie
2023-08-03 20:21 ` jim.cromie
2023-08-03 20:21 ` jim.cromie
2023-08-01 17:02 ` [PATCH v5 20/22] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 21/22] dyndbg-doc: add classmap info to howto Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:02 ` [PATCH v5 22/22] checkpatch: reword long-line warn about commit-msg Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` Jim Cromie
2023-08-01 17:02 ` [Intel-gfx] " Jim Cromie
2023-08-01 17:57 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fix DRM_USE_DYNAMIC_DEBUG regression (rev3) Patchwork
2023-08-01 17:57 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
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=20230801170255.163237-3-jim.cromie@gmail.com \
--to=jim.cromie@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@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=jani.nikula@intel.com \
--cc=jbaron@akamai.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=robdclark@gmail.com \
--cc=seanpaul@chromium.org \
--cc=ville.syrjala@linux.intel.com \
/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.