lkml.org 
[lkml]   [2011]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] printk: allow setting DEFAULT_MESSAGE_LEVEL via Kconfig
On 01/28/2011 04:57 AM, Mandeep Singh Baines wrote:
> Alexey Dobriyan (adobriyan@gmail.com) wrote:
>> On Wed, Jan 26, 2011 at 03:10:17PM -0800, Andrew Morton wrote:
>>> On Wed, 26 Jan 2011 14:57:03 -0800
>>> Randy Dunlap <rdunlap@xenotime.net> wrote:
>>>
>>>>> I'm a bit surprised that this wasn't already tunable at boot-time
>>>>> and/or at runtime.
>>>>
>>>>
>>>> As WANG Cong replied:
>>>>
>>>> Why? We already have "loglevel=" kernel parameter.
>>>
>>> That's different.
>>>
>>> Mandeep's patch addresses printks which didn't have a facility level.
>>
>> For those, we have ignore_loglevel kernel parameter.
>
> That's a little different. ignore_loglevel will print ALL kernel messages
> to the console. What we would like to do is look at all messages that
> are KERN_WARNING (and higher in priority) very closely. Bugs lie there;)
> Problem is that DEFAULT_MESSAGE_LEVEL is KERN_WARNING so there is too
> much noise at KERN_WARNING. So we'd like to be able to set
> DEFAULT_MESSAGE_LEVEL (default_message_loglevel) to something lower in,
> priority, at boot or earlier. You can set it via /proc/sys/kernel/printk
> (takes an int_vec) but that's too late. A ton of stuff has already been
> logged by the time we're able to change a sysctl.

Why not make printk prefix messages that have no log level with
"[NO_LOG_LEVEL]" or similar? That way the can easily be grepped out, and
it provides and incentive for people to fix them :-).

~Ryan

--
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934


\
 
 \ /
  Last update: 2011-01-27 21:47    [W:0.098 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site