public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Cc: Jayamohan Kallickal <jayamohan.kallickal@avagotech.com>,
	Ketan Mukadam <ketan.mukadam@avagotech.com>,
	John Soni Jose <sony.john@avagotech.com>,
	"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] be2iscsi: Logging neatening
Date: Tue, 16 Aug 2016 20:39:02 -0700	[thread overview]
Message-ID: <1471405142.4075.197.camel@perches.com> (raw)
In-Reply-To: <SN1PR0201MB18700901B51BE24AE75EC18D81140@SN1PR0201MB1870.namprd02.prod.outlook.com>

On Wed, 2016-08-17 at 01:19 +0000, Bart Van Assche wrote:
> 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.
[]
> > 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.
[]
> 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.

Many of these logging mechanisms are not just debug
facilities.

Perhaps a dynamic_debug control would be inappropriate.

There have also been various custom scsi log level
facilities like the blogic_msg for the very old
BusLogic blogic_msg.

These functions also sometimes write into some
device-specific buffer.

Perhaps the largest problem, if this is to be scsi only
rather than system wide, is finding out what and how
the various bits in a mask should be used.

  reply	other threads:[~2016-08-17  3:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-12 10:02 [PATCH 2/2] be2iscsi: Fix some error messages Christophe JAILLET
2016-08-12 10:30 ` Julia Lawall
2016-08-12 20:30   ` Christophe JAILLET
2016-08-13  7:08     ` [PATCH 2/2 v2] " Christophe JAILLET
2016-08-13  7:14       ` Julia Lawall
2016-08-13  7:20     ` [PATCH 2/2 v3] " Christophe JAILLET
2016-08-13 11:35       ` Joe Perches
2016-08-13 12:31         ` Christophe JAILLET
2016-08-13 16:41           ` Joe Perches
2016-08-13 17:03             ` Joe Perches
2016-08-13 20:42               ` [PATCH 0/2] be2iscsi: Logging neatening Joe Perches
2016-08-13 20:42                 ` [PATCH 1/2] be2iscsi: Coalesce split strings and formats Joe Perches
2016-08-13 20:42                 ` [PATCH 2/2] be2iscsi: Use a standard logging style Joe Perches
2016-08-14 14:34                 ` [PATCH 0/2] be2iscsi: Logging neatening Bart Van Assche
2016-08-14 16:24                   ` Joe Perches
2016-08-14 17:09                     ` Bart Van Assche
2016-08-14 17:29                       ` Joe Perches
2016-08-17  1:19                         ` Bart Van Assche
2016-08-17  3:39                           ` Joe Perches [this message]
2016-08-14 18:55                     ` [PATCH] be2iscsi: Use a more current logging style Joe Perches
2016-08-16  6:02                       ` Jitendra Bhivare
2016-08-16 10:27                         ` Joe Perches
2016-08-17  3:50                           ` Jitendra Bhivare
2016-08-17  3:59                             ` Joe Perches

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=1471405142.4075.197.camel@perches.com \
    --to=joe@perches.com \
    --cc=Bart.VanAssche@sandisk.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=jayamohan.kallickal@avagotech.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=ketan.mukadam@avagotech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sony.john@avagotech.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox