From: Martin Schwidefsky <schwidefsky@de.ibm.com>
From: Michael Holzheu <holzheu@de.ibm.com>

Introduce a new family of printk macros which prefixes each kmsg message
with a component name and allows to tag the message with a 24 bit hash of
the message text. The kmsg component name is defined per source file with
the KMSG_COMPONENT macro. In order to use the kmsg_xxx macros KMSG_COMPONENT
has to be defined.

If the message hash will be printed to the console / syslog at all depends
on CONFIG_MSG_IDS. If it is "n" then a kmsg_xxx call is just another
printk wrapper. These macros are intended to be used uniformly in the
s390 architecture and the s390 device drivers.

Signed-off-by: Michael Holzheu <holzheu@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---

 arch/s390/Kconfig    |    9 +++++++++
 include/linux/kmsg.h |   42 ++++++++++++++++++++++++++++++++++++++++++
 kernel/printk.c      |   24 ++++++++++++++++++++++++
 3 files changed, 75 insertions(+)

Index: kmsg-2.6/arch/s390/Kconfig
===================================================================
--- kmsg-2.6.orig/arch/s390/Kconfig
+++ kmsg-2.6/arch/s390/Kconfig
@@ -571,6 +571,15 @@ bool "s390 guest support (EXPERIMENTAL)"
 	select VIRTIO_CONSOLE
 	help
 	  Select this option if you want to run the kernel under s390 linux
+
+config KMSG_IDS
+	bool "Kernel message numbers"
+	default y
+	help
+	  Select this option if you want to include a message number to the
+	  prefix for kernel messages issued by the s390 architecture and
+	  driver code. See "Documentation/s390/kmsg.txt" for more details.
+
 endmenu
 
 source "net/Kconfig"
Index: kmsg-2.6/include/linux/kmsg.h
===================================================================
--- /dev/null
+++ kmsg-2.6/include/linux/kmsg.h
@@ -0,0 +1,42 @@
+#ifndef _LINUX_KMSG_H
+#define _LINUX_KMSG_H
+
+#define kmsg_printk(level, format, ...) \
+	printk(level KMSG_COMPONENT  ": " format, ##__VA_ARGS__)
+
+#if defined(__KMSG_CHECKER)
+/* ...
[ message continues ]

Now I'm going to be an asshole and ask you to define when each of these levels 
should be used.  Do we need all of them?

Thanks,
Rusty.
--

[ message continues ]

These are just the regular printk levels. If your old printk used a
particular level, have the kmsg_xxx printk use the same level. The
question about message severity and message documenation are
independent, aren't they?

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.


--

[ message continues ]

Yes, but since it's a new message API, I thought you might have an idea.  It's 
hard for authors (eg. me) to know which level to use.  As a result, levels 
currently seem to be chosen randomly.

If you felt inspired to rationalize them, it would let us clean that up as 
things moved to kmsg :)

Cheers,
Rusty.
--

[ message continues ]

Urgs, you are after a sort of definition what the differences is between
a warning, an error, an alert, etc is, aren't you?

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.


--

[ message continues ]

And it is a sign of my admiration for your intellect that I asked you for it.  
(Does that help?)

Rusty.
--

[ message continues ]

Rusty,

Since Kernel message levels are used directly by syslog, the Open Group Base 
Specifications Issue 6 defines what these levels are:
http://www.opengroup.org/onlinepubs/009695399/basedefs/syslog.h.html

LOG_EMERG
A panic condition was reported to all processes.
LOG_ALERT
A condition that should be corrected immediately.
LOG_CRIT
A critical condition.
LOG_ERR
An error message.
LOG_WARNING
A warning message.
LOG_NOTICE
A condition requiring special handling.
LOG_INFO
A general information message.
LOG_DEBUG
A message useful for debugging programs.

I dont think, that the kernel should define anything different.
We could add a more verbose description or a howto to CodingStyle later on, 
but this is really orthogonal to kmsg and would be valid for printk, 
dev_printk and any other printk wrapper.

Futhermore, this really smells like a bike shed color question and IMHO we 
should not hold of the kmsg patches to answer this kind of controversial 
questions ;-)

Christian 
--

[ message continues ]