From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90A41C433E0 for ; Tue, 9 Jun 2020 11:16:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 631E3207F9 for ; Tue, 9 Jun 2020 11:16:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591701379; bh=xU2wxxxrsLRWawYxncEIYiWeqskYMvCbos9vXfMghc4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=w0Gffe8n0y04HimPB1QcbqGPLSWJzeOXrNKwvu9lyLzxKfcmiGsdHrY80e78c/kwf W5GWpf6AhRl3deXCvYfLW7ynN1RmKmYZl2gWTBABpM4g9qb19ZqCFFCrMVgoFRt2Bl SAxMxuHMII1jOpwk5HY3zSM27d9xB6zyM23hW7vw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728153AbgFILQS (ORCPT ); Tue, 9 Jun 2020 07:16:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:41230 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726083AbgFILQS (ORCPT ); Tue, 9 Jun 2020 07:16:18 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 50236207ED; Tue, 9 Jun 2020 11:16:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591701377; bh=xU2wxxxrsLRWawYxncEIYiWeqskYMvCbos9vXfMghc4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fvtwVxjvZX99zxaniwh1G9/o2C8apo21iA4dq2KWDskckwppNIRJ7QPE53zLAXYIc uBRlDf2dbCmgFsC0L1EUriB6WOyjiI5+3kKbIm+iBUHkklkqL/+wNHQlTMei9K6B15 rbg0aciyOuk2Uh1MInUEg34BZpUyEO9NZkiVt2aA= Date: Tue, 9 Jun 2020 13:16:15 +0200 From: Greg Kroah-Hartman To: Stanimir Varbanov Cc: linux-doc@vger.kernel.org, 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, Joe Perches , Jason Baron , Jonathan Corbet Subject: Re: [PATCH v3 1/7] Documentation: dynamic-debug: Add description of level bitmask Message-ID: <20200609111615.GD780233@kroah.com> References: <20200609104604.1594-1-stanimir.varbanov@linaro.org> <20200609104604.1594-2-stanimir.varbanov@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200609104604.1594-2-stanimir.varbanov@linaro.org> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Tue, Jun 09, 2020 at 01:45:58PM +0300, Stanimir Varbanov wrote: > This adds description of the level bitmask feature. > > Cc: Jonathan Corbet (maintainer:DOCUMENTATION) > > Signed-off-by: Stanimir Varbanov > --- > Documentation/admin-guide/dynamic-debug-howto.rst | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst > index 0dc2eb8e44e5..c2b751fc8a17 100644 > --- a/Documentation/admin-guide/dynamic-debug-howto.rst > +++ b/Documentation/admin-guide/dynamic-debug-howto.rst > @@ -208,6 +208,12 @@ line > line -1605 // the 1605 lines from line 1 to line 1605 > line 1600- // all lines from line 1600 to the end of the file > > +level > + The given level will be a bitmask ANDed with the level of the each ``pr_debug()`` > + callsite. This will allow to group debug messages and show only those of the > + same level. The -p flag takes precedence over the given level. Note that we can > + have up to five groups of debug messages. As was pointed out, this isn't a "level", it's some arbitrary type of "grouping". But step back, why? What is wrong with the existing control of dynamic debug messages that you want to add another type of arbitrary grouping to it? And who defines that grouping? Will it be driver/subsystem/arch/author specific? Or kernel-wide? This feels like it could easily get out of hand really quickly. Why not just use tracepoints if you really want to be fine-grained? thanks, greg k-h