From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753487AbcHQByn (ORCPT ); Tue, 16 Aug 2016 21:54:43 -0400 Received: from mail-sn1nam01on0085.outbound.protection.outlook.com ([104.47.32.85]:16568 "EHLO NAM01-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752700AbcHQByl (ORCPT ); Tue, 16 Aug 2016 21:54:41 -0400 From: Bart Van Assche To: Joe Perches , Christophe JAILLET , "linux-scsi@vger.kernel.org" CC: Jayamohan Kallickal , Ketan Mukadam , John Soni Jose , "James E.J. Bottomley" , "Martin K. Petersen" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 0/2] be2iscsi: Logging neatening Thread-Topic: [PATCH 0/2] be2iscsi: Logging neatening Thread-Index: AQHR9jkCpu9Zs20Pc0K6xjrD6emduw== Date: Wed, 17 Aug 2016 01:19:39 +0000 Message-ID: References: <1471107782.3467.28.camel@perches.com> <1471191843.4075.39.camel@perches.com> <1471195790.4075.45.camel@perches.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bart.VanAssche@sandisk.com; x-originating-ip: [73.15.202.106] x-ms-office365-filtering-correlation-id: 3a6b5d94-d7eb-4761-6ac2-08d3c63c8f4b x-microsoft-exchange-diagnostics: 1;SN1PR0201MB1871;20:iblSJ4AiPb5xW48KVOnJVReTQmcLEBrFSX1LnwNM3oVzW+d+aWTDj4alq83rwVI3f8v4Q2m2p3DJPqiXqXZISNHOXt6GxP45NPl2qT/CQukohthmMInY86R6rm9YlyNA/CAhtfPeYN4uG2zlXG8Ud7bUEwLSr3nelD+N7rSF11tWw7ZvPU83138eey409XipsclqP7Dc2ZNRml2iW0tXsjnOVwPbtQKDQNzHEvf1oJOtILZFO9N+XmrZ24DdLwgW x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1871; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:SN1PR0201MB1871;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0201MB1871; x-forefront-prvs: 0037FD6480 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(24454002)(52314003)(377424004)(199003)(189002)(10400500002)(54356999)(7736002)(122556002)(305945005)(74316002)(3280700002)(2501003)(2906002)(7696003)(86362001)(7846002)(92566002)(87936001)(3660700001)(76176999)(50986999)(5002640100001)(106356001)(106116001)(68736007)(11100500001)(586003)(4326007)(189998001)(99286002)(101416001)(76576001)(105586002)(561944003)(5001770100001)(77096005)(66066001)(93886004)(97736004)(2900100001)(81156014)(8676002)(81166006)(3846002)(33656002)(6116002)(8936002)(9686002)(102836003);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR0201MB1871;H:SN1PR0201MB1870.namprd02.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2016 01:19:39.2642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1871 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u7H1sls0013549 On 08/14/16 10:29, Joe Perches wrote: > On Sun, 2016-08-14 at 17:09 +0000, Bart Van Assche wrote: >> My primary concern is how to enable and disable log messages from user >> space. Many drivers define their own logging macros and export a bitmask >> that allows to enable and disable logging messages per category. These >> bitmask control mechanisms are annoying because figuring out what bit >> controls which message category requires a search through the driver >> source code. I'd like to see all these custom logging macros disappear >> and being replaced by a single mechanism. The "dynamic debug" mechanism >> e.g. is in my opinion much easier to use than the different custom >> logging mechanisms. > > Dynamic debug doesn't have a bitmask function and > still requires looking through the code for lines > and format strings. > > I think you are looking for a system wide equivalent > for the ethtool/netif_ mechanism. > > Nothing like that exists currently. > > Some code uses a bitmask/and, other code uses a > level/comparison. > > Care to propose something? Hello Joe, As far as I can see all that the ethtool msglevel API implements is a mechanism to query and set the log level from user space. What various SCSI drivers implement is not a log level but a log mask mechanism. How about the following approach to associate a name with each bit in a log mask, to export these names to user space and to make it possible to enable/disable messages per log category: * Introduce a variant of pr_debug() that allows to specify a textual representation of the log category (a short string without spaces). * Make the log category names available in /sys/kernel/debug/dynamic_debug/... * Today dynamic debug allows to enable/disable log messages by specifying the source file name, function name, line number, module name and/or format string. My proposal is to make it also possible to enable/disable log messages based on the log category name. Anyway, this is just a proposal. Anyone is welcome to come up with an alternative proposal. Bart.