Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <6115b15ced02686f7408417411ff758445b42421.camel@perches.com>
Subject: Re: [PATCH v3 0/7] Venus dynamic debug
From:   Joe Perches <joe@perches.com>
To:     jim.cromie@gmail.com,
        Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc:     Randy Dunlap <rdunlap@infradead.org>,
        Matthew Wilcox <willy@infradead.org>,
        Linux Documentation List <linux-doc@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, linux-media@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, linux-btrfs@vger.kernel.org,
        linux-acpi@vger.kernel.org, netdev@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jason Baron <jbaron@akamai.com>
Date:   Tue, 09 Jun 2020 15:23:07 -0700
In-Reply-To: <CAJfuBxwyDysP30cMWDusw4CsSQitchA5hOKkpk1PktbsbCKTSw@mail.gmail.com>
References: <20200609104604.1594-1-stanimir.varbanov@linaro.org>
         <20200609111323.GA19604@bombadil.infradead.org>
         <c239d5df-e069-2091-589e-30f341c2cbd3@infradead.org>
         <9a79aded6981ec47f1f8b317b784e6e44158ac61.camel@perches.com>
         <CAJfuBxwyDysP30cMWDusw4CsSQitchA5hOKkpk1PktbsbCKTSw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
User-Agent: Evolution 3.36.2-0ubuntu1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2020-06-09 at 15:21 -0600, jim.cromie@gmail.com wrote:
> On Tue, Jun 9, 2020 at 10:49 AM Joe Perches <joe@perches.com> wrote:
> > (adding Jim Cromie and comments)
> > On Tue, 2020-06-09 at 09:03 -0700, Randy Dunlap wrote:
> > > On 6/9/20 4:13 AM, Matthew Wilcox wrote:
> > > > On Tue, Jun 09, 2020 at 01:45:57PM +0300, Stanimir Varbanov wrote:
> > > > > Here is the third version of dynamic debug improvements in Venus
> > > > > driver.  As has been suggested on previous version by Joe [1] I've
> > > > > made the relevant changes in dynamic debug core to handle leveling
> > > > > as more generic way and not open-code/workaround it in the driver.
> > > > > 
> > > > > About changes:
> > > > >  - added change in the dynamic_debug and in documentation
> > > > >  - added respective pr_debug_level and dev_dbg_level
> > > > 
> > > > Honestly, this seems like you want to use tracepoints, not dynamic debug.
> > 
> > Tracepoints are a bit heavy and do not have any class
> > or grouping mechanism.
> > 
> > debug_class is likely a better name than debug_level
> > 
> > > Also see this patch series:
> > > https://lore.kernel.org/lkml/20200605162645.289174-1-jim.cromie@gmail.com/
> > > [PATCH 00/16] dynamic_debug: cleanups, 2 features
> > > 
> > > It adds/expands dynamic debug flags quite a bit.
> > 
> > Yes, and thanks Randy and Jim and Stanimir
> > 
> > I haven't gone through Jim's proposal enough yet.
> > It's unfortunate these patches series conflict.
> > 
> > And for Jim, a link to Stanimir's patch series:
> > https://lore.kernel.org/lkml/20200609104604.1594-1-stanimir.varbanov@linaro.org/
> > 
> > 
> 
> As Joe noted, there is a lot of ad-hockery to possibly clean up,
> but I dont grok how these levels should be distinguished from
> KERN_(WARN|INFO|DEBUG) constants.

These are not KERN_<LEVEL> at all, all are emitted at KERN_DEBUG

These are just driver developer mechanisms to enable/disable
groups of formats via some test for < level or | bitmap

> Those constants are used by coders, partly to convey how bad things are
> As a user, Id be reluctant to disable an EMERG callsite.

Not possible.

> are you trying to add a User Bit ? or maybe 7-9 of them ?

Or maybe a u32/ulong worth as most as I think the largest
current use is 32 bits of bitmask.

> I have a patchset which adds a 'u' flag, for user.

Adapting that with an external bool for bitmask or class
would work fine.

	if (is_bitmask)
		enable/disable(value|flag)
	else
		enable/disable(value < flag)

So the equivalent of logical sets would work just fine.