From: walter harms <wharms@bfs.de>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/16] drivers/net/ethernet/ibm/emac/mal.c: use WARN
Date: Sat, 03 Nov 2012 16:26:40 +0000 [thread overview]
Message-ID: <509545C0.5050000@bfs.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1211031513220.1955@localhost6.localdomain6>
Am 03.11.2012 15:14, schrieb Julia Lawall:
> On Sat, 3 Nov 2012, walter harms wrote:
>
>>
>>
>> Am 03.11.2012 11:58, schrieb Julia Lawall:
>>> From: Julia Lawall <Julia.Lawall@lip6.fr>
>>>
>>> Use WARN rather than printk followed by WARN_ON(1), for conciseness.
>>>
>>> A simplified version of the semantic patch that makes this
>>> transformation
>>> is as follows: (http://coccinelle.lip6.fr/)
>>>
>>> // <smpl>
>>> @@
>>> expression list es;
>>> @@
>>>
>>> -printk(
>>> +WARN(1,
>>> es);
>>> -WARN_ON(1);
>>> // </smpl>
>>>
>>> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>>>
>>> ---
>>> drivers/net/ethernet/ibm/emac/mal.c | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/ibm/emac/mal.c
>>> b/drivers/net/ethernet/ibm/emac/mal.c
>>> index 479e43e..84c6b6c 100644
>>> --- a/drivers/net/ethernet/ibm/emac/mal.c
>>> +++ b/drivers/net/ethernet/ibm/emac/mal.c
>>> @@ -738,13 +738,11 @@ static int __devexit mal_remove(struct
>>> platform_device *ofdev)
>>> /* Synchronize with scheduled polling */
>>> napi_disable(&mal->napi);
>>>
>>> - if (!list_empty(&mal->list)) {
>>> + if (!list_empty(&mal->list))
>>> /* This is *very* bad */
>>> - printk(KERN_EMERG
>>> + WARN(1, KERN_EMERG
>>> "mal%d: commac list is not empty on remove!\n",
>>> mal->index);
>>> - WARN_ON(1);
>>> - }
>>>
>>> dev_set_drvdata(&ofdev->dev, NULL);
>>>
>>>
>>
>> Hi Julia,
>> you are removing the {} behin the if. I prefer to be a bit conservative
>> about {}. There is suggest to keep them because WARN may be expanded in
>> future (with a second line) and that will cause subtle changes that do
>> no break the code. (Yes i know it is possible to write macros that
>> contain savely more than one line.)
>
> WARN is already multi-line, surrounded by ({ }). It seems to be set up
> to be used as an expression. Is it necessary to assume that it might
> someday be changed from safe to unsafe?
>
my bad,
NTL looks like a candidate for a function.
While looking i have noticed that a lot of drivers define there private "assert" macro.
It is very similar to warn.
(e.g.)
#define RTL819x_DEBUG
#ifdef RTL819x_DEBUG
#define assert(expr) \
if (!(expr)) { \
printk( "Assertion failed! %s,%s,%s,line=%d\n", \
#expr,__FILE__,__FUNCTION__,__LINE__); \
}
re,
wh
WARNING: multiple messages have this Message-ID (diff)
From: walter harms <wharms@bfs.de>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/16] drivers/net/ethernet/ibm/emac/mal.c: use WARN
Date: Sat, 03 Nov 2012 17:26:40 +0100 [thread overview]
Message-ID: <509545C0.5050000@bfs.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1211031513220.1955@localhost6.localdomain6>
Am 03.11.2012 15:14, schrieb Julia Lawall:
> On Sat, 3 Nov 2012, walter harms wrote:
>
>>
>>
>> Am 03.11.2012 11:58, schrieb Julia Lawall:
>>> From: Julia Lawall <Julia.Lawall@lip6.fr>
>>>
>>> Use WARN rather than printk followed by WARN_ON(1), for conciseness.
>>>
>>> A simplified version of the semantic patch that makes this
>>> transformation
>>> is as follows: (http://coccinelle.lip6.fr/)
>>>
>>> // <smpl>
>>> @@
>>> expression list es;
>>> @@
>>>
>>> -printk(
>>> +WARN(1,
>>> es);
>>> -WARN_ON(1);
>>> // </smpl>
>>>
>>> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>>>
>>> ---
>>> drivers/net/ethernet/ibm/emac/mal.c | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/ibm/emac/mal.c
>>> b/drivers/net/ethernet/ibm/emac/mal.c
>>> index 479e43e..84c6b6c 100644
>>> --- a/drivers/net/ethernet/ibm/emac/mal.c
>>> +++ b/drivers/net/ethernet/ibm/emac/mal.c
>>> @@ -738,13 +738,11 @@ static int __devexit mal_remove(struct
>>> platform_device *ofdev)
>>> /* Synchronize with scheduled polling */
>>> napi_disable(&mal->napi);
>>>
>>> - if (!list_empty(&mal->list)) {
>>> + if (!list_empty(&mal->list))
>>> /* This is *very* bad */
>>> - printk(KERN_EMERG
>>> + WARN(1, KERN_EMERG
>>> "mal%d: commac list is not empty on remove!\n",
>>> mal->index);
>>> - WARN_ON(1);
>>> - }
>>>
>>> dev_set_drvdata(&ofdev->dev, NULL);
>>>
>>>
>>
>> Hi Julia,
>> you are removing the {} behin the if. I prefer to be a bit conservative
>> about {}. There is suggest to keep them because WARN may be expanded in
>> future (with a second line) and that will cause subtle changes that do
>> no break the code. (Yes i know it is possible to write macros that
>> contain savely more than one line.)
>
> WARN is already multi-line, surrounded by ({ }). It seems to be set up
> to be used as an expression. Is it necessary to assume that it might
> someday be changed from safe to unsafe?
>
my bad,
NTL looks like a candidate for a function.
While looking i have noticed that a lot of drivers define there private "assert" macro.
It is very similar to warn.
(e.g.)
#define RTL819x_DEBUG
#ifdef RTL819x_DEBUG
#define assert(expr) \
if (!(expr)) { \
printk( "Assertion failed! %s,%s,%s,line=%d\n", \
#expr,__FILE__,__FUNCTION__,__LINE__); \
}
re,
wh
next prev parent reply other threads:[~2012-11-03 16:26 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-03 10:58 [PATCH 0/16] use WARN Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 1/16] drivers/gpu/drm/drm_cache.c: use WARN_ONCE Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 2/16] fs/hfsplus/bnode.c: use WARN Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-04 10:49 ` Vyacheslav Dubeyko
2012-11-04 11:49 ` Vyacheslav Dubeyko
2012-11-03 10:58 ` [PATCH 3/16] drivers/md/raid5.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 4/16] drivers/usb/wusbcore: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 5/16] drivers/scsi: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 6/16] drivers/infiniband/hw/cxgb4/cm.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
[not found] ` <1351940317-14812-7-git-send-email-Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
2012-11-03 12:40 ` Steve Wise
2012-11-03 12:40 ` Steve Wise
2012-11-03 12:40 ` Steve Wise
2012-11-03 10:58 ` [PATCH 7/16] drivers/scsi/gdth.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 8/16] drivers/infiniband/hw/cxgb3/iwch_cm.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
[not found] ` <1351940317-14812-9-git-send-email-Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
2012-11-03 12:39 ` Steve Wise
2012-11-03 12:39 ` Steve Wise
2012-11-03 12:39 ` Steve Wise
2012-11-03 10:58 ` [PATCH 9/16] fs/ext4/indirect.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2013-02-02 1:07 ` Theodore Ts'o
2013-02-02 1:07 ` Theodore Ts'o
2012-11-03 10:58 ` [PATCH 10/16] drivers/net/ethernet/ibm/emac/mal.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 11:30 ` walter harms
2012-11-03 11:30 ` walter harms
2012-11-03 14:14 ` Julia Lawall
2012-11-03 14:14 ` Julia Lawall
2012-11-03 16:26 ` walter harms [this message]
2012-11-03 16:26 ` walter harms
2012-11-03 16:35 ` Julia Lawall
2012-11-03 16:35 ` Julia Lawall
2012-11-03 19:43 ` David Miller
2012-11-03 19:43 ` David Miller
2012-11-03 10:58 ` [PATCH 11/16] drivers/misc/kgdbts.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 12:11 ` walter harms
2012-11-03 12:11 ` walter harms
2012-11-03 14:26 ` [PATCH] drivers/misc/kgdbts.c: remove eprintk Julia Lawall
2012-11-03 14:26 ` Julia Lawall
2012-11-04 19:39 ` Arnd Bergmann
2012-11-04 19:39 ` Arnd Bergmann
2012-11-04 19:58 ` Julia Lawall
2012-11-04 19:58 ` Julia Lawall
2012-11-04 20:51 ` Arnd Bergmann
2012-11-04 20:51 ` Arnd Bergmann
2012-11-04 21:04 ` Julia Lawall
2012-11-04 21:04 ` Julia Lawall
2012-11-05 16:26 ` Arnd Bergmann
2012-11-05 16:26 ` Arnd Bergmann
2012-11-05 16:57 ` Julia Lawall
2012-11-05 16:57 ` Julia Lawall
2012-11-05 20:01 ` Arnd Bergmann
2012-11-05 20:01 ` Arnd Bergmann
2012-11-03 10:58 ` [PATCH 12/16] fs/logfs/gc.c: use WARN Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 13/16] fs/btrfs: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-05 15:38 ` David Sterba
2012-11-05 15:38 ` David Sterba
2012-11-03 10:58 ` [PATCH 14/16] drivers/ssb/main.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 15/16] drivers/parisc/pdc_stable.c: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
2012-11-03 10:58 ` [PATCH 16/16] drivers/infiniband/hw/nes: " Julia Lawall
2012-11-03 10:58 ` Julia Lawall
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=509545C0.5050000@bfs.de \
--to=wharms@bfs.de \
--cc=julia.lawall@lip6.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.