Adding KERN_INFO to some printks #2

Primary purpose of this patch is to make KERN_WARNING and KERN_INFO log levels closer to their original meaning. Today they are quite far from what was intended. Just look what kernel writes at the WARNING level each time you boot your box!

When I was making this patch I couldn't resist and fixed messed up tabs around affected printks, wrapped some lines longer than 80 columns, fixed some typos.
My formatting preferences:
* log entries are started with capital letters except for function/modules names in lowercase or acronyms (IDE etc)
* Dot before \n is a waste of space
* colon style: "Foo: blah blan" (not "Foo : blah" or "Foo: Blah") But I'm not a religious fanatic: it ok to disagree with me :-) You can see in the patch that I wasn't overly distracted by this decorative work.

I'm doing my best trying not to break working code. However, if you feel paranoid today you may remove any hunk of this patch you may deem suspicious and apply the rest - all these changes are independent.

If you like this patch but have more interesting things to play with, you may do the following:
* clear your logs
* reconfigure syslogd to spew warnings to /var/log/syslog.warnings
* reboot
* mail boot time "warnings" which you think are not warnings but info only ("104-key keyboard detected"-type msgs) to me - I'll add fixes for those to this patch.

Patch can be found at
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/KERN_INFO-2.4.13.diff

or emailed on request (our www server isn't exactly powerful, you may have difficulty downloading the patch)
--
vda

This is an _excellent_ patch and you should proffer it to Linus and Alan when you are done. I would recommend diffing off 2.4.14 instead of 2.4.13, to this end.

I haven't gone over the actual loglevel warnings, but I plan to. A quick glimpse shows you are changing what needs to be changed. Good job.

Yah it was slow but it worked :)

Robert Love

Well... thanks man.
I hope patch will be noticed by our tribal leaders :-) (Linus? Alan?)

Rediffed patch against 2.4.15-pre1 can be found at
http://port.imtp.ilyichevsk.odessa.ua/linux/vda/KERN_INFO-2.4.15-pre1.diff

or emailed on request (our www server isn't exactly powerful, you may have difficulty downloading the patch)
--------
Primary purpose of this patch is to make KERN_WARNING and KERN_INFO log levels closer to their original meaning. Today they are quite far from what was intended.
Just look what kernel writes at the WARNING level
each time you boot your box!

When I was making this patch I couldn't resist and fixed messed up tabs around affected printks, wrapped some lines longer than 80 columns, fixed some typos.
My formatting preferences:
* log entries are started with capital letters except for function/modules names in lowercase or acronyms (IDE etc)
* Dot before \n is a waste of space
* colon style: "Foo: blah blan" (not "Foo : blah" or "Foo: Blah") But I'm not a religious fanatic: it ok to disagree with me :-) You can see in the patch that I wasn't overly distracted by this decorative work.

I'm doing my best trying not to break working code. However, if you feel paranoid today you may remove any hunk of this patch you may deem suspicious and apply the rest - all these changes are independent of each other, you may even just ignore rejects if you are patching newer/older kernel!

If you like this patch but have more interesting things to play with, you may do the following:
* clear your logs
* reconfigure syslogd to spew warnings to /var/log/syslog.warnings
* reboot
* mail boot time "warnings" which you think are not warnings but info only ("104-key keyboard detected"-type msgs) to me - I'll add fixes for those msgs to this patch
--
vda

Its not at the top of my list right now. I want to get the merge with Linus done before attacking anything newer

What amazes me to no end is how Alan can be so active. Alan, you are something. Really. :-)

I will keep rediffing patches against newer kernels and announcing diffs. Take them when you are ready.
--
vda

Didn't you hear? I think Linus broke the news awhile back: Alan has the uncanny ability to fork() himself infinitely many times. And he has no resource contention, so he scales O(1).

Robert Love

That was the "thousand gnomes" message:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.0/0274.html

Suspiciously, there was no denial. :)

-George Greer

Alan is really busy stuffing patches off to Linus, and thus he is more concerned with getting Linus's 2.4.15 up to sync with him right now. Linus is probably busy with that, too. If you don't see this in a Linus -pre, 2.5.0 is also right around the tree.

I think the most important thing you are doing is adding loglevel values to printk statements that have none -- that is important not just to clarify and make sure the value is right, but because the default loglevel can and will change (it has before).

I went over the patch and found a few things...

printk(KERN_INFO "No local APIC present or hardware disabled\n");

I'd make this a KERN_WARNING. Consider the case where I compile my own
kernel and I add APIC support. If the driver is failing to find my APIC then either (a) my BIOS is broken or (b) I should remove the driver. Either way I would want to know.

printk (KERN_WARNING "mtrr: your CPUs had inconsistent fixed MTRR printk (KERN_WARNING "mtrr: your CPUs had inconsistent variable MTRR printk (KERN_WARNING "mtrr: your CPUs had inconsistent MTRRdefType printk (KERN_WARNING "mtrr: probably your BIOS does not setup all

These can actually be KERN_INFO, because it is not a problem and the
mtrr driver fixes the issue.

There are a _lot_ of printk statements in your patch where you didn't add a loglevel. You modified them for some reason (in many cases to change printk("%s" ...) to printk(pf: ...). You can easily find them via a search on `printk("' ... that same search can be a grep to find on-specified printks in the whole tree, too :)

Good work.

Robert Love

Ok I'll do

I'd rather not overdo my patch. Better leave some KERN_WARNINGs where they are now than hide something important. I am concentrated on killing _obviously_ informative msgs.

I modified printks which were hard to find due to lack of any greppable [ :-) ] string. Next poor soul will be more lucky :-)

I don't think adding log levels massively is good: I'd like to see real world bogus warning log files and fix only those ('don't overdo it' policy)
--
vda

This isn't what's happening - check apic.c. It is re-enabled if possible, or a local APIC really doesn't exist. Either way I don't see the point in a warning.

regards
john

"I know I believe in nothing but it is my nothing"
	- Manic Street Preachers