From: Michael Holzheu <[email protected]>
From: Martin Schwidefsky <[email protected]>
Introduce a new family of printk macros which prefixes each kmsg message
with a component name and allows to tag the printk with a message id.
The kmsg component name is defined per source file with the KMSG_COMPONENT
macro. The first argument of each kmsg printk is the message id. The
message id "0" is special as it will suppress the message id prefix.
If the message id 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 <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
---
arch/s390/Kconfig | 9 +++
include/asm-s390/kmsg.h | 124 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 133 insertions(+)
Index: quilt-2.6/arch/s390/Kconfig
===================================================================
--- quilt-2.6.orig/arch/s390/Kconfig
+++ quilt-2.6/arch/s390/Kconfig
@@ -568,6 +568,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: quilt-2.6/include/asm-s390/kmsg.h
===================================================================
--- /dev/null
+++ quilt-2.6/include/asm-s390/kmsg.h
@@ -0,0 +1,124 @@
+#ifndef _ASM_KMSG_H
+#define _ASM_KMSG_H
+
+#ifndef __KMSG_CHECKER
+#define __KMSG_CHECK(level, id) KERN_##level
+#endif
+
+#if defined(__KMSG_CHECKER) || !defined(CONFIG_KMSG_IDS)
+
+#define kmsg_dev_alert(id, dev, format, arg...) \
+ printk(__KMSG_CHECK(ALERT, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_err(id, dev, format, arg...) \
+ printk(__KMSG_CHECK(ERR, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_warn(id, dev, format, arg...) \
+ printk(__KMSG_CHECK(WARNING, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_info(id, dev, format, arg...) \
+ printk(__KMSG_CHECK(INFO, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_notice(id, dev, format, arg...) \
+ printk(__KMSG_CHECK(NOTICE, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_alert(id, format, arg...) \
+ printk(__KMSG_CHECK(ALERT, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_err(id, format, arg...) \
+ printk(__KMSG_CHECK(ERR, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_warn(id, format, arg...) \
+ printk(__KMSG_CHECK(WARNING, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_info(id, format, arg...) \
+ printk(__KMSG_CHECK(INFO, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_notice(id, format, arg...) \
+ printk(__KMSG_CHECK(NOTICE, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#else /* __KMSG_CHECKER || !CONFIG_KMSG_IDS */
+
+#define kmsg_dev_alert(id, dev, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(ALERT, id) KMSG_COMPONENT \
+ "." #id ": %s: " format, (dev)->bus_id , ## arg) : \
+ printk(__KMSG_CHECK(ALERT, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_err(id, dev, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(ERR, id) KMSG_COMPONENT \
+ "." #id ": %s: " format, (dev)->bus_id , ## arg) : \
+ printk(__KMSG_CHECK(ERR, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_warn(id, dev, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(WARNING, id) KMSG_COMPONENT \
+ "." #id ": %s: " format, (dev)->bus_id , ## arg) : \
+ printk(__KMSG_CHECK(WARNING, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_info(id, dev, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(INFO, id) KMSG_COMPONENT \
+ "." #id ": %s: " format, (dev)->bus_id , ## arg) : \
+ printk(__KMSG_CHECK(INFO, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_dev_notice(id, dev, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(NOTICE, id) KMSG_COMPONENT \
+ "." #id ": %s: " format, (dev)->bus_id , ## arg) : \
+ printk(__KMSG_CHECK(NOTICE, id) KMSG_COMPONENT \
+ ": %s: " format, (dev)->bus_id , ## arg)
+
+#define kmsg_alert(id, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(ALERT, id) KMSG_COMPONENT \
+ "." #id ": " format, ## arg) : \
+ printk(__KMSG_CHECK(ALERT, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_err(id, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(ERR, id) KMSG_COMPONENT \
+ "." #id ": " format, ## arg) : \
+ printk(__KMSG_CHECK(ERR, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_warn(id, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(WARNING, id) KMSG_COMPONENT \
+ "." #id ": " format, ## arg) : \
+ printk(__KMSG_CHECK(WARNING, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_info(id, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(INFO, id) KMSG_COMPONENT \
+ "." #id ": " format, ## arg) : \
+ printk(__KMSG_CHECK(INFO, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#define kmsg_notice(id, format, arg...) \
+ (__builtin_constant_p(id) && (id) > 0) ? \
+ printk(__KMSG_CHECK(NOTICE, id) KMSG_COMPONENT \
+ "." #id ": " format, ## arg) : \
+ printk(__KMSG_CHECK(NOTICE, id) KMSG_COMPONENT \
+ ": " format, ## arg)
+
+#endif /* __KMSG_CHECKER || !CONFIG_KMSG_IDS */
+
+#endif /* _ASM_KMSG_H */
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Mon, 2008-07-28 at 19:53 +0200, Martin Schwidefsky wrote:
> The kmsg component name is defined per source file with the KMSG_COMPONENT
> macro.
Why not use KBUILD_MODNAME?
On Mon, 2008-07-28 at 11:12 -0700, Joe Perches wrote:
> On Mon, 2008-07-28 at 19:53 +0200, Martin Schwidefsky wrote:
> > The kmsg component name is defined per source file with the KMSG_COMPONENT
> > macro.
>
> Why not use KBUILD_MODNAME?
Because sometimes we might want to use the same kmsg prefix for multiple
modules. And the message tag is supposed to stay the same even if the
code structure changes. I'd rather not use KBUILD_MODNAME.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Mon, 28 Jul 2008 19:53:56 +0200 Martin Schwidefsky <[email protected]> wrote:
> Introduce a new family of printk macros which prefixes each kmsg message
> with a component name and allows to tag the printk with a message id.
>
> The kmsg component name is defined per source file with the KMSG_COMPONENT
> macro. The first argument of each kmsg printk is the message id. The
> message id "0" is special as it will suppress the message id prefix.
>
> If the message id 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 <[email protected]>
> Signed-off-by: Martin Schwidefsky <[email protected]>
> ---
>
> arch/s390/Kconfig | 9 +++
> include/asm-s390/kmsg.h | 124 ++++++++++++++++++++++++++++++++++++++++++++++++
Numerous people want a facility like this for other-than-s390 use.
Progress has been intermittent and appears to have stopped. The
apparently-dead mailing list is archived here:
https://lists.linux-foundation.org/pipermail/lf_kernel_messages/.
I don't know what the future holds for that development effort, but the
requirement won't go away. So one day someone is going to go and yank
your implementation out of arch/s390 and into generic code.
So I'd suggest that you start out that way.
On Wed, 2008-07-30 at 01:30 -0700, Andrew Morton wrote:
> On Mon, 28 Jul 2008 19:53:56 +0200 Martin Schwidefsky <[email protected]> wrote:
> Numerous people want a facility like this for other-than-s390 use.
> Progress has been intermittent and appears to have stopped. The
> apparently-dead mailing list is archived here:
> https://lists.linux-foundation.org/pipermail/lf_kernel_messages/.
>
> I don't know what the future holds for that development effort, but the
> requirement won't go away. So one day someone is going to go and yank
> your implementation out of arch/s390 and into generic code.
>
> So I'd suggest that you start out that way.
Somehow I have hoped for an answer like that :-) The only thing that
we'd have to do is find a proper place for the kmsg header file,
include/linux/kmsg.h comes to mind. The kmsg-doc script can easily be
change to check for multiple documentation directories, I was thinking
about Documentation/kmsg/$ARCH for the architecture specific things and
Documentation/kmsg for the generic parts.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Wed, 30 Jul 2008 11:13:41 +0200 Martin Schwidefsky <[email protected]> wrote:
> On Wed, 2008-07-30 at 01:30 -0700, Andrew Morton wrote:
> > On Mon, 28 Jul 2008 19:53:56 +0200 Martin Schwidefsky <[email protected]> wrote:
> > Numerous people want a facility like this for other-than-s390 use.
> > Progress has been intermittent and appears to have stopped. The
> > apparently-dead mailing list is archived here:
> > https://lists.linux-foundation.org/pipermail/lf_kernel_messages/.
> >
> > I don't know what the future holds for that development effort, but the
> > requirement won't go away. So one day someone is going to go and yank
> > your implementation out of arch/s390 and into generic code.
> >
> > So I'd suggest that you start out that way.
>
> Somehow I have hoped for an answer like that :-) The only thing that
> we'd have to do is find a proper place for the kmsg header file,
> include/linux/kmsg.h comes to mind. The kmsg-doc script can easily be
> change to check for multiple documentation directories, I was thinking
> about Documentation/kmsg/$ARCH for the architecture specific things and
> Documentation/kmsg for the generic parts.
>
No objections from me.
It would be wonderful if someone could troll those list archives and
see if they can wake up the people who were involved in that effort.
They probably won't help much with development but it would be useful if
we could get their review/design input.