Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 7 Sep 2022 17:08:36 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Jim Cromie <jim.cromie@gmail.com>
Cc:     jbaron@akamai.com, dri-devel@lists.freedesktop.org,
        amd-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org,
        intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        daniel.vetter@ffwll.ch, seanpaul@chromium.org, robdclark@gmail.com,
        linux@rasmusvillemoes.dk, joe@perches.com
Subject: Re: [PATCH v6 00/57] DYNDBG: opt-in class'd debug for modules, use
 in drm.
Message-ID: <Yxiz9HsBusNAad3Z@kroah.com>
References: <20220904214134.408619-1-jim.cromie@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220904214134.408619-1-jim.cromie@gmail.com>
Precedence: bulk

On Sun, Sep 04, 2022 at 03:40:37PM -0600, Jim Cromie wrote:
> hi Greg, Jason, DRM-folk, Steven,
> 
> If Im not too late for linux-next in this cycle, heres V6.  Diffs are minor:
> 
>  - rebased onto e47eb90a0a9a (tag: next-20220901, linux-next/master)
>    gets past Kconfig conflict, same for drm-tip.
>  - uint debug_level, not ulong.  to fit nouveau.
>  - -1 on param-read-back, to match prev write val.
>  - added back tracefs parts, missing from -V5
>    updated for tracing/events: Add __vstring() and __assign_vstr() helper macros
>    no decorations-lite in TP_printk, do it right later.
>  - commit-msg tweaks
> 
> Theres also new RFC stuff with the potential to reduce the size of the
> __dyndbgs section by 20%.  Not ready for prime time, or linux-next,
> but I hope compelling.
> 
> FEATURE DESCRIPTION
> 
> dyndbg provides DECLARE_DYNAMIC_DEBUG_CLASSMAP() which allows module
> authors to declare "good" class-names, of 4 types.
> 
>   DYNAMIC_DEBUG_CLASSMAP(drm_debug_classes,
>   			DD_CLASS_TYPE_DISJOINT_BITS, offset,
>                         "DRM_UT_CORE",
>                         "DRM_UT_DRIVER",
>                         "DRM_UT_KMS",
>                         "DRM_UT_PRIME",
>                         "DRM_UT_ATOMIC",
>                         "DRM_UT_VBL",
>                         "DRM_UT_STATE",
>                         "DRM_UT_LEASE",
>                         "DRM_UT_DP",
>                         "DRM_UT_DRMRES");
> 
> That usage authorizes dyndbg to set class'd pr_debugs accordingly:
> 
>   echo class DRM_UT_CORE +p > /proc/dynamic_debug/control
>   echo class DRM_UT_KMS  +p > /proc/dynamic_debug/control
> 
> Because the DRM modules declare the same classes, they each authorize
> dyndbg with the same classnames, which allows dyndbg to effect changes
> to its selected class'd prdbgs.
> 
> Opting in by using the macro effectively privatizes the limited
> 63-classes available per module; only modules which share classnames
> must coordinate their use of the common range, and they can
> independently use the remaining id-space.
> 
> Other dyndbg filtering pertains too, so single sites can be selected.
> 
> 
> 4 DD_CLASS_TYPE_*_*s determine 2 behaviors:
> 
>   DISJOINT	bits are independent, like drm.debug categories
>   LEVELs	3>2, turns on level-2, like nouveau debug-levels
>   NUM/BITS	numeric input, bitmap if disjoint, else 0-32.
>   NAMES		accept proper names, like DRM_UT_CORE
> 
> Dyndbg provides param-callbacks which enforce those behaviors:
> 
>   # DISJOINT_BITS
>   echo 0x03 > /sys/module/drm/parameters/debug
> 
>   # LEVEL_NUM
>   echo 3 > /sys/module/drm/nouveau/debug-mumble*
> 
>   # DISJOINT_NAMES
>   echo +DRM_UT_CORE,+DRM_UT_KMS,-DRM_UT_DRIVER > /sys/module/drm/parameters/debug_categories
> 
>   # LEVEL_NAMES
>   echo NV_TRACE > /sys/module/nouveau/parameters/debug-mumble*
> 
> That design choice is allowed cuz verbosity is always attached to a
> (user visible) interface, and theres no reason not to put the
> implementation there (in the callback).  It also considerably
> simplifies things; ddebug_change can treat class_id's as disjoint,
> period.
> 

I've applied the first 21 patches in this series to my
driver-core-testing branch, and if 0-day doesn't blow up on it, I'll
move it to my -next branch tomorrow and it will get a wider testing
range in the linux-next releases.

Feel free to rebase the rest of the series on top of my tree and
resubmit after addressing Daniel's comments.

thanks,

greg k-h