From: Rusty Russell <rusty@rustcorp.com.au>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"Andrew V. Savochkin" <saw@saw.sw.com.sg>,
cgl_discussion mailing list <cgl_discussion@osdl.org>,
evlog mailing list <evlog-developers@lists.sourceforge.net>,
"ipslinux (Keith Mitchell)" <ipslinux@us.ibm.com>,
Linus Torvalds <torvalds@home.transmeta.com>,
Hien Nguyen <hien@us.ibm.com>,
James Keniston <kenistoj@us.ibm.com>,
Mike Sullivan <sullivam@us.ibm.com>
Subject: Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)
Date: Tue, 24 Sep 2002 16:58:12 +1000 [thread overview]
Message-ID: <20020924070706.D84CA2C1A7@lists.samba.org> (raw)
In-Reply-To: Your message of "Tue, 24 Sep 2002 02:11:56 -0400." <3D90022C.3060300@pobox.com>
In message <3D90022C.3060300@pobox.com> you write:
> right, that's a bug, it needs struct net_device * like the standard
> Becker style.
And Andrey Savochkin is no idiot. But if he had a standard
problem-reporting macro to guide him, he wouldn't have done this.
>
> >>>- printk (KERN_ERR "eepro100: cannot reserve MMIO region\n");
> >>>+ pci_problem(LOG_ERR, pdev, "eepro100: cannot reserve MMIO regio
> >>
> > n");
> >
> >>bloat, no advantage over printk
> >
> >
> > Now, which of those 5 cards was it again?
>
> Another bug, this driver should be using pci_request_regions() which
> prints that stuff out :)
Ditto.
> Does IBM want to submit a patch that cleans up these problems, and makes
> the existing event logging more standard [and is compatible with
> existing 2.4 and 2.5 kernels]?
(Um, this is supposed to go into the 2.5 kernel, so the last arg is
void).
This doesn't deprecate printk(). It just formalizes printk() for
problem reporting inside drivers. As we see more tools come out
making this useful, I expect drivers will willingly change across.
You can ensure that each message says what the driver name and kernel
version is if you want, *without* changing every driver.
You can do this with some "printk templates", but *that* would be too
ugly to live:
#include <linux/net_templates.h>
...
printk(NETPROBLEM_27, dev, skb);
...
> As an aside, changing all those printks also introduces a _huge_ PITA
> for driver developers porting drivers back and forth between 2.4 and 2.5.
That's not a good reason. compat.h can define them into printks with
a bit of cpp magic. In fact, Werner already wrote that. Hmm... the
one in the patch they posted is not based on Werner's, but my older
work. It should look vaguely like:
/* Do not meddle in the affairs of cpp, for it is subtle, and quick to anger */
#define __detS_
#define __detV_
#define __detS_detail(label,format,value) " " #label "=" format
#define __detV_detail(label,format,value) value,
#define __detV_3(detail) detail
#define __detV_2(detail,...) detail __detV_3( __detV_ ## __VA_ARGS__)
#define __detV_1(detail,...) detail __detV_2( __detV_ ## __VA_ARGS__)
#define __detS_3(detail) detail
#define __detS_2(detail,...) detail __detS_3( __detS_ ## __VA_ARGS__)
#define __detS_1(detail,...) detail __detS_2( __detS_ ## __VA_ARGS__)
#define recovered(id, msg, ...) \
printk(KERN_WARNING "%p:%s:" __detS_1( __detS_ ## __VA_ARGS__) "%c", \
id, msg, __detV_1( __detV_ ## __VA_ARGS__) '\n')
#define problem(id, msg, ...) \
printk(KERN_ERR "%p:%s:" __detS_1( __detS_ ## __VA_ARGS__) "%c", \
id, msg, __detV_1( __detV_ ## __VA_ARGS__) '\n')
#define introduce(id, name, ...) \
printk(KERN_INFO "Introducing %p:%s:" \
__detS_1( __detS_ ## __VA_ARGS__) "%c", \
id, msg, __detV_1( __detV_ ## __VA_ARGS__) '\n')
#define unintroduce(id) \
printk(KERN_INFO "Unintroducing %p\n", id)
================
Now, these were the previous macros which didn't have a severity arg,
but you get the idea.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2002-09-24 7:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-24 1:55 [PATCH-RFC] README 1ST - New problem logging macros (2.5.38) Larry Kessler
2002-09-24 2:40 ` Jeff Garzik
2002-09-24 5:55 ` Rusty Russell
2002-09-24 6:11 ` Jeff Garzik
2002-09-24 6:58 ` Rusty Russell [this message]
2002-09-24 5:15 ` Greg KH
2002-09-24 5:28 ` Jeff Garzik
2002-09-26 18:56 ` Larry Kessler
2002-09-26 19:38 ` Rik van Riel
2002-09-26 20:01 ` Larry Kessler
2002-09-26 18:41 ` Rob Landley
2002-09-24 5:58 ` Greg KH
2002-09-24 16:32 ` Patrick Mochel
2002-09-24 8:36 ` Andrey Savochkin
-- strict thread matches above, loose matches on Subject: below --
2002-09-24 4:49 [PATCH-RFC] " Larry Kessler
2002-09-24 12:58 ` Denis Vlasenko
2002-09-24 13:59 ` Gerhard Mack
2002-09-24 22:38 ` Thunder from the hill
2002-09-24 4:56 Jeff Garzik
2002-09-24 14:04 Randal, Phil
2002-09-24 14:15 ` Sven Koch
2002-09-26 15:43 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020924070706.D84CA2C1A7@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cgl_discussion@osdl.org \
--cc=evlog-developers@lists.sourceforge.net \
--cc=hien@us.ibm.com \
--cc=ipslinux@us.ibm.com \
--cc=jgarzik@pobox.com \
--cc=kenistoj@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=saw@saw.sw.com.sg \
--cc=sullivam@us.ibm.com \
--cc=torvalds@home.transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox