[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47FBF285.4090201@trash.net>
Date: Wed, 09 Apr 2008 00:32:37 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Joe Perches <joe@...ches.com>
CC: David Miller <davem@...emloft.net>, johannes@...solutions.net,
harvey.harrison@...il.com, netdev@...r.kernel.org
Subject: Re: New sparse warning in net/mac80211/debugfs_sta.c
Joe Perches wrote:
> On Tue, 2008-04-08 at 23:19 +0200, Patrick McHardy wrote:
>> This might work (codiff should be able to tell). But I
>> just see that Dave also favours to use MAC_FMT directly,
>> so please just do this.
>
> Precisely what are you objecting to Patrick?
>
> Are you objecting to the existence of an additional
> function call in a printk or the unnecessary call to
> print_mac in functions like pr_debug that the compiler
> can not optimize away?
>
> Your long list seems to be mostly a list of functions
> that are converted from direct use of MAC_FMT with
> 6 arguments on stack to a call to print_mac.
>
> I think the only things that should be changed are those
> functions that add a useless call to print_mac because
> pr_debug is optimized away.
>
> I do _not_ think that merely because print_mac is used
> as a printk argument it should be reverted.
No, those cases probably don't matter, if there was a printk
before it can't matter that much. What should be removed is
cases like virtio_net:
static int start_xmit(struct sk_buff *skb, struct net_device *dev)
{
...
pr_debug("%s: xmit %p %s\n", dev->name, skb, print_mac(mac, dest));
which adds a unconditional and useless function call in a
performance critical path.
You could probably generate a better starting point than
my codiff somehow, I just redefined print_mac to
"00:00:00:00:00:00", which means it doesn't care whether
its in a printk or a pr_debug() call. Might be quicker
to go through the list manually though.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists