From: Johannes Berg <[EMAIL PROTECTED]>
Date: Mon, 25 Feb 2008 21:05:42 +0100
>
> On Mon, 2008-02-25 at 20:56 +0100, Johannes Berg wrote:
> > On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote:
> > > From: Johannes Berg <[EMAIL PROTECTED]>
> > > Date: Mon, 25 Feb 2008 10:53:48 +0100
> > >
> >
From: Johannes Berg <[EMAIL PROTECTED]>
Date: Mon, 25 Feb 2008 20:56:43 +0100
>
> On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote:
> > From: Johannes Berg <[EMAIL PROTECTED]>
> > Date: Mon, 25 Feb 2008 10:53:48 +0100
> >
> > > Maybe we should just add a new printf modifier like %M for MAC
On Mon, 2008-02-25 at 20:56 +0100, Johannes Berg wrote:
> On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote:
> > From: Johannes Berg <[EMAIL PROTECTED]>
> > Date: Mon, 25 Feb 2008 10:53:48 +0100
> >
> > > Maybe we should just add a new printf modifier like %M for MAC
> > > addresses? Then we
On Mon, 2008-02-25 at 12:47 +0100, Patrick McHardy wrote:
> It would be good if Joe could go through the remaining print_mac users
> and convert the remaining unintended function calls in fastpaths back
> to MAC_FMT. Grepping for "start_xmit" in commit 0795af5729b shows that
> at least 10 hard_sta
On Mon, 2008-02-25 at 11:52 -0800, David Miller wrote:
> From: Johannes Berg <[EMAIL PROTECTED]>
> Date: Mon, 25 Feb 2008 10:53:48 +0100
>
> > Maybe we should just add a new printf modifier like %M for MAC
> > addresses? Then we could use sprintf, snprintf, printk and whatever we
> > please witho
From: Johannes Berg <[EMAIL PROTECTED]>
Date: Mon, 25 Feb 2008 10:53:48 +0100
> Maybe we should just add a new printf modifier like %M for MAC
> addresses? Then we could use sprintf, snprintf, printk and whatever we
> please without any of the macro stuff...
But GCC has no idea what the heck it i
> > Maybe we should just add a new printf modifier like %M for MAC
> > addresses? Then we could use sprintf, snprintf, printk and whatever we
> > please without any of the macro stuff...
>
> Could gcc validate the printf %M arguments?
No, but it won't barf on it either, it silently ignores unkno
On Mon, 2008-02-25 at 10:53 +0100, Johannes Berg wrote:
> On Sat, 2008-02-23 at 20:02 -0800, David Miller wrote:
> > From: Patrick McHardy <[EMAIL PROTECTED]>
> > Date: Thu, 21 Feb 2008 19:00:03 +0100
> >
> > > And adds back the overhead of two completely unnecessary
> > > function calls to the V
On Mon, 2008-02-25 at 10:53 +0100, Johannes Berg wrote:
> Maybe we should just add a new printf modifier like %M for MAC
> addresses? Then we could use sprintf, snprintf, printk and whatever we
> please without any of the macro stuff...
Could gcc validate the printf %M arguments?
Another possibil
David Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 19:00:03 +0100
And adds back the overhead of two completely unnecessary
function calls to the VLAN fastpath. How about just
stopping this idiocy and reverting the appropriate patches
to bring back MAC_FMT an
On Sat, 2008-02-23 at 20:02 -0800, David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 19:00:03 +0100
>
> > And adds back the overhead of two completely unnecessary
> > function calls to the VLAN fastpath. How about just
> > stopping this idiocy and reverting
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 19:00:03 +0100
> And adds back the overhead of two completely unnecessary
> function calls to the VLAN fastpath. How about just
> stopping this idiocy and reverting the appropriate patches
> to bring back MAC_FMT and use it where app
Patrick McHardy wrote:
Joe Perches wrote:
This removes the __pure from print_mac, so reject as appropriate...
Add some type safety to print_mac by using struct print_mac_buf *
instead of char *.
And adds back the overhead of two completely unnecessary
function calls to the VLAN fastpath.
Joe Perches wrote:
On Thu, 2008-02-21 at 11:17 +0100, Johannes Berg wrote:
Yeah, I saw that discussion. I think it's fine, it's just something we
need to be aware of. In fact, I Joe had a patch (that seems to have
gotten lost?) to make DECLARE_MAC_BUF() declare a structure with the u8
pointer
On Thu, 2008-02-21 at 11:17 +0100, Johannes Berg wrote:
> Yeah, I saw that discussion. I think it's fine, it's just something we
> need to be aware of. In fact, I Joe had a patch (that seems to have
> gotten lost?) to make DECLARE_MAC_BUF() declare a structure with the u8
> pointer in it instead to
David Miller wrote:
From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 02:01:19 -0800
In this case, it's being passed to a debugfs create function, could it
instead use sysfs_format_mac?
Just assigning print_mac() to a local variable then passing that to
debugfs_create_dir() wil
On Thu, 2008-02-21 at 02:05 -0800, David Miller wrote:
> >From another perspective adding that __pure attribute to print_mac()
> might not have been the best idea. But I can't think of another
> way to eliminate the "passing print_mac() args to pr_debug()
> still generates calls to print_mac() eve
On Thu, 2008-02-21 at 02:05 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 02:01:19 -0800
>
> > In this case, it's being passed to a debugfs create function, could it
> > instead use sysfs_format_mac?
>
> Just assigning print_mac() to a local vari
On Thu, 2008-02-21 at 02:12 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 02:08:18 -0800
>
> > Really, that should have read:
> >
> > Sparse warning introduced since -rc2:
> > ..etc
> >
> > Harvey's best guess is this commit...
>
> I think the c
On Thu, 2008-02-21 at 02:05 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 02:01:19 -0800
>
> > In this case, it's being passed to a debugfs create function, could it
> > instead use sysfs_format_mac?
>
> Just assigning print_mac() to a local varia
From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 02:08:18 -0800
> Really, that should have read:
>
> Sparse warning introduced since -rc2:
> ..etc
>
> Harvey's best guess is this commit...
I think the commit you originally blamed got added in 2.6.24,
so it would be very difficul
On Thu, 2008-02-21 at 02:03 -0800, David Miller wrote:
> From: Johannes Berg <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 10:54:59 +0100
>
> > It modifies the buffer, and I think it's more likely that the warning
> > was introduced by
> ...
> > [NET]: Elminate spurious print_mac() calls.
>
>
From: Johannes Berg <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 10:54:59 +0100
> It modifies the buffer, and I think it's more likely that the warning
> was introduced by
...
> [NET]: Elminate spurious print_mac() calls.
Right and that's what I just suggested in another reply.
Harvey how did
From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 02:01:19 -0800
> In this case, it's being passed to a debugfs create function, could it
> instead use sysfs_format_mac?
Just assigning print_mac() to a local variable then passing that to
debugfs_create_dir() will make the warning g
On Thu, 2008-02-21 at 01:57 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 01:34:27 -0800
>
> > commit 0795af5729b18218767fab27c44b1384f72dc9ad
> > Author: Joe Perches <[EMAIL PROTECTED]>
> > Date: Wed Oct 3 17:59:30 2007 -0700
> >
> > [NET]:
On Thu, 2008-02-21 at 01:34 -0800, Harvey Harrison wrote:
> commit 0795af5729b18218767fab27c44b1384f72dc9ad
> Author: Joe Perches <[EMAIL PROTECTED]>
> Date: Wed Oct 3 17:59:30 2007 -0700
>
> [NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()
>
> This is nicer than the MAC_
commit 0795af5729b18218767fab27c44b1384f72dc9ad
Author: Joe Perches <[EMAIL PROTECTED]>
Date: Wed Oct 3 17:59:30 2007 -0700
[NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()
This is nicer than the MAC_FMT stuff.
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Si
27 matches
Mail list logo
