Re: [PATCH 1/1] net/wireless/ibss.c: replace memcpy by ether_addr_copy

[Joe Perches <joe@perches.com>]

On Mon, 2014-05-12 at 20:51 +0200, Johannes Berg wrote:
> On Mon, 2014-05-12 at 11:07 -0700, Joe Perches wrote:
> > On Mon, 2014-05-12 at 20:00 +0200, Fabian Frederick wrote:
> > > On Mon, 12 May 2014 10:50:25 -0700
> > > Joe Perches <joe@perches.com> wrote:
> > > > On Mon, 2014-05-12 at 19:30 +0200, Fabian Frederick wrote:
> > > > > This patch also fixes some comment checkpatch warnings
> > > > For all the patches that replace memcpy(foo, bar, ETH_ALEN)
> > > > with ether_addr_copy, did you use a tool to verify both
> > > > arguments are __aligned(2) or did you do the verification
> > > > visually?
> > > I only replaced ETH_ALEN/memcpy .
> > > AFAICS ETH_ALEN is defined 6 ...
> > 
> > The difference here is that both arguments to
> > ether_addr_copy, like all the is_<foo>_ether_addr
> > helpers, must be __aligned(2).  memcpy has
> > no alignment requirement.
> > 
> > Please verify that all these changes are to
> > __aligned(2) arguments.
> 
> Seriously though, who cares. Only two of these patches really touch
> paths where performance matters - and one of those is the lib80211 one
> which is practically only used for certain ancient Intel devices, which
> probably don't run on anything but IA where I'd guess the whole thing
> doesn't really matter anyway.
> 
> I certainly don't see the benefit in changing all those other files,
> particularly since it's not just that we have to verify alignment *now*,
> we also have to add alignment attributes so that we don't break
> alignment in the future.

The same alignment requirements exist in quite a
lot of the code so I don't see that as much of a
continuing problem.

It's more of an initial conversion problem.

> Additionally doesn't even really save much typing:
> 
> memcpy(x, y, ETH_ALEN);
> ether_addr_copy(x, y);

To me the general benefit isn't in the reduced
source code size, but small improvements for
ARM both in code size and execution speed.

I'm not sure it's worth even the initial conversion
verification costs though.  It's quite tedious to
go through the call trees and I don't know of an
automated way to do that.