netdev - Re: [PATCH] etherdevice: introduce eth_broadcast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1341991654.4480.5.camel@jlt3.sipsolutions.net>
Date:	Wed, 11 Jul 2012 09:27:34 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: [PATCH] etherdevice: introduce eth_broadcast_addr

On Tue, 2012-07-10 at 20:09 -0400, Paul Gortmaker wrote:
> On Tue, Jul 10, 2012 at 12:18 PM, Johannes Berg
> <johannes@...solutions.net> wrote:
> > From: Johannes Berg <johannes.berg@...el.com>
> >
> > A lot of code has either the memset or an inefficient copy
> > from a static array that contains the all-ones broadcast
> 
> Shouldn't we see all that "lot of code" here in this same
> commit, now using this new shortcut?  If we apply this, we
> have a new function, but with no users.  If you have done
> the audit, and found the inefficient cases, why isn't it here?

I'm planning to fix the wireless uses (at least the ones I'm responsible
for), but I'm just going to stick them into my mac80211-next tree after
this patch percolates down there, I don't see a need to send around a
ton of patches for it.

> I would think it better to just fix those people who have a
> pointless static array of all-ones to use the memset.  If it was a
> multi line thing to achieve the eth_broadcast_addr() then it
> might make sense to exist.  But as a one line alias, it does
> seem somewhat pointless to me.

At least in my code I'm going to prefer this over the memset for
documentation purposes. I'll agree that memset(..., 0xff, ETH_ALEN) is
pretty obvious already, but eth_broadcast_addr(...) is even easier to
read IMHO.

johannes

--
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