linux-kernel - Re: + remove-current-defines-and-uses-of-pr_err-add-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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 08 Aug 2007 14:36:16 -0700
From:	Joe Perches <joe@...ches.com>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, mm-commits@...r.kernel.org,
	adaplas@....net, greg@...ah.com, jeff@...zik.org
Subject: Re: + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patch
	added to -mm tree

On Wed, 2007-08-08 at 22:39 +0200, Jan Engelhardt wrote:
> I fail to see what problem these are trying to fix. 

Any code that does the equivalent of printk(KERN_foo "\n message");

egrep -r "printk[[:space:]]*\([[:space:]]*KERN.*\\\n[A-JL-Za-jl-z[:space:]" --include=*.[ch] *

At least 61 instances right now.

> Please post some broken code that would 'benefit' from pr_halleluja,
> and why printk(level ) could not do the same.

"Could" most always leads to an interesting argument.

Future minimization of introduced error is a benefit
not an absolute.

Adding the ability to log higher priority KERN_<level>
without removing printk altogether for embedded systems
seems useful.  You could leave out say just KERN_INFO,
KERN_NOTICE and KERN_WARN levels.

Worth the churn is another question, though git seems to
allow most everyone to resync to tree wide changes pretty
easily.

If new pr_<level> defines aren't accepted, I suggest
removing the current ~200 uses of pr_info.

> >8 Minimization/elimination of interleaved log messages
> 
> This is a separate, and worthwhile, thing to do, yes.
> And it can be done without deviating from the regular printk().

I'm not sure how.  Maybe you have an idea you could share?

Maybe an external tool to reassemble complete messages from
prefixed {{cookie}} message logs would be fine for awhile.

Perhaps something like:

cookie = printk_block_start()
printk_block[s](cookie)
printk_block_end(cookie)?

where printk_block emits cookie when multiple cookies
are active.

cheers,  Joe

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