From: Adrian Bunk <bunk@fs.tum.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.27-pre2: tg3: there's no WARN_ON in 2.4
Date: Fri, 14 May 2004 00:34:36 +0200 [thread overview]
Message-ID: <20040513223436.GI22202@fs.tum.de> (raw)
In-Reply-To: <c7rpsg$ghd$1@terminus.zytor.com>
On Wed, May 12, 2004 at 12:07:44AM +0000, H. Peter Anvin wrote:
> Followup to: <20040506121302.GI9636@fs.tum.de>
> By author: Adrian Bunk <bunk@fs.tum.de>
> In newsgroup: linux.dev.kernel
> > > >
> > > >yep. Either we backport WARN_ON ;) or simply do the attached.
> > > >
> > > >--- old/drivers/net/tg3.c 2004-05-04 14:30:22.000000000 +0200
> > > >+++ new/drivers/net/tg3.c 2004-05-04 14:49:58.000000000 +0200
> > > >@@ -51,6 +51,10 @@
> > > > #define TG3_TSO_SUPPORT 0
> > > > #endif
> > > >
> > > >+#ifndef WARN_ON
> > > >+#define WARN_ON(x) do { } while (0)
> > > >+#endif
> > >
> > > Related but off topic. Do people find the ab#define WARN_ON(x)
> > > a macro acceptable? The fact is that not mentioning 'x' means any
> > > side-effects are not executed, meaning the author must take special
> > > care when using this macro.
> > >...
> >
> > Do not use code with side effects in BUG_ON and WARN_ON.
> >
>
> Why not use the much simpler:
>
> #ifndef WARN_ON
> # define WARN_ON(x) ((void)(x))
> #endif
>
> Preserves side effects and everything.
AFAIR, the -tiny tree already implements some kind of empty
BUG/PAGE_BUG/WARN_ON macros.
When optimizing for size that way, your suggestion would result in
bigger code.
And after a quick view, I haven't seen any WARN_ON users in 2.6 that
seem to rely on side effects.
> -hpa
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2004-05-13 22:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-03 23:09 Linux 2.4.27-pre2 Marcelo Tosatti
2004-05-04 3:49 ` Frédéric L. W. Meunier
2004-05-04 19:19 ` Linux 2.4.27-pre2 (gcc-3.4.0) Rafał 'rmrmg' Roszak
[not found] ` <200405042146.40404@WOLK>
2004-05-04 20:03 ` Rafał 'rmrmg' Roszak
2004-05-05 6:36 ` Rene Rebe
2004-05-05 8:15 ` Rafał 'rmrmg' Roszak
2004-05-05 9:30 ` Mikael Pettersson
2004-05-05 9:53 ` Rene Rebe
2004-05-05 10:20 ` Mikael Pettersson
2004-05-04 20:46 ` 2.4.27-pre2: tg3: there's no WARN_ON in 2.4 Adrian Bunk
2004-05-04 20:53 ` Marc-Christian Petersen
2004-05-04 20:56 ` Jeff Garzik
2004-05-05 3:18 ` David S. Miller
2004-05-05 8:57 ` Marc-Christian Petersen
2004-05-05 19:30 ` David S. Miller
2004-05-04 23:44 ` Eyal Lebedinsky
2004-05-06 12:13 ` Adrian Bunk
2004-05-12 0:07 ` H. Peter Anvin
2004-05-13 22:34 ` Adrian Bunk [this message]
2004-05-13 23:03 ` H. Peter Anvin
2004-05-17 0:38 ` Adrian Bunk
2004-05-05 23:50 ` Linux 2.4.27-pre2 Eyal Lebedinsky
2004-05-07 13:49 ` Marcelo Tosatti
2004-05-19 18:14 ` [2.4 patch] hotplug: add missing Configure.help entries Adrian Bunk
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=20040513223436.GI22202@fs.tum.de \
--to=bunk@fs.tum.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/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