linux-ext4 - Re: [PATCH 2/9] ext4: Use pr_fmt and pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1332438152.4677.25.camel@joe2Laptop>
Date:	Thu, 22 Mar 2012 10:42:32 -0700
From:	Joe Perches <joe@...ches.com>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	Jiri Slaby <jirislaby@...il.com>, Ted Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/9] ext4: Use pr_fmt and pr_<level>

On Thu, 2012-03-22 at 18:02 +0100, Jiri Slaby wrote:
> On 03/20/2012 10:46 AM, Joe Perches wrote:
> > On Tue, 2012-03-20 at 10:25 +0100, Jiri Slaby wrote:
> >> On 03/20/2012 10:21 AM, Joe Perches wrote:
> >>> the ath5k pr_ conversion patches are to
> >>> standardize prefixes and to reduce code size by
> >>> centralizing tests.
> >> What is the "standard" prefix?
> > KBUILD_MODNAME
> 
> Instead, we should switch as many printks to dev_* and similar as
> possible, right?

I believe logging message use should be selected
to be as specific as possible (from high to low):

o <subsystem>_<level>
o netif_<level>
o netdev_<level>
o dev_<level>
o pr_<level>
o printk(KERN_<LEVEL>

> They are standard and provide a good interface for
> extensions: one has a device to work with. This is something what pr_*
> does not offer.

I completely agree.

I'd like to see some new subsystem prefixes
created and used as well.  Maybe:

fs_<level> (like Ted's ext4_<foo>)
io_<level> (scsi/ide/mtd)
mm_<level>

There are probably a few others like
cpu/video/sound that might be useful.

> Frankly, moving the debug code to a separate function should make the
> code rather faster. By moving the unlikely code out of the instruction
> cache.

I think it's better still to eliminate debug
code altogether via if (0) when reasonable
or use dynamic_debug (jump_tables) when
overall code size isn't an issue.

cheers, Joe

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html