From: Greg KH <gregkh@suse.de>
To: Sven Eckelmann <sven.eckelmann@gmx.de>
Cc: tklauser@distanz.ch, b.a.t.m.a.n@lists.open-mesh.org,
Marek Lindner <lindner_marek@yahoo.de>,
siwu@hrz.tu-chemnitz.de
Subject: Re: [B.A.T.M.A.N.] patch "staging: batman-adv: Use linux/etherdevice.h address helper functions" added to staging tree
Date: Wed, 10 Nov 2010 17:11:37 -0800 [thread overview]
Message-ID: <20101111011137.GA23112@suse.de> (raw)
In-Reply-To: <201011101746.42904.sven.eckelmann@gmx.de>
On Wed, Nov 10, 2010 at 05:46:37PM +0100, Sven Eckelmann wrote:
> On Wednesday 10 November 2010 17:04:55 Greg KH wrote:
> > > I'm wondering why you accepted this patch despite the raised objections
> > > regarding alignment problems. [1][2]
> >
> > Because at the end of that thread, it sounded like you all agreed that
> > this patch was acceptable.
> >
> > If not, then please let me know and I will revert it.
>
> The end of the thread was that he should remove parts of the patch and resent
> it - or prove that all the data is 2 bytes aligned.
>
>
> On Wednesday 03 November 2010 11:56:19 Sven Eckelmann wrote:
> [...]
> > > I don't think they need to be two bytes aligned, but I might be wrong.
> >
> > compare_ether_addr uses a two byte pointer to access 3x two bytes. This
> > makes it necessary to have all those 3 bytes aligned to 2 byte boundaries.
> [correction sent later: "6x two bytes aligned to 2 byte boundaries"]
> > Otherwise the compiler has to generate special instructions on
> > architectures which don't support loads on non-aligned addresses. Usually
> > he doesn't do it unless he has some indications that it is necessary
> > (__attribute__ ((packed)) for example).
> >
> > There is also documentation available on that topic in
> > Documentation/unaligned-memory-access.txt
> >
> > And maybe it is good to use is_broadcast_ether_addr, but leave
> > compare_ether_addr part open (or prove that we always have those two
> > operands correctly aligned).
> [...]
>
> None of that happened yet. And yes, this wasn't the last mail we sent to him
> to get some response - no answer till now.
Oops, my fault, I've now reverted this patch, sorry about that.
thanks,
greg k-h
next prev parent reply other threads:[~2010-11-11 1:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <12893476522148@site>
2010-11-10 10:17 ` [B.A.T.M.A.N.] patch "staging: batman-adv: Use linux/etherdevice.h address helper functions" added to staging tree Marek Lindner
2010-11-10 16:04 ` Greg KH
2010-11-10 16:46 ` Sven Eckelmann
2010-11-11 1:11 ` Greg KH [this message]
2010-11-11 10:34 ` Marek Lindner
2010-11-11 8:52 ` Tobias Klauser
[not found] ` <BAY127-W15AD53BC245C1D430CF07BCF360@phx.gbl>
2010-11-15 10:21 ` Marek Lindner
2010-11-17 16:32 ` Marek Lindner
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=20101111011137.GA23112@suse.de \
--to=gregkh@suse.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=lindner_marek@yahoo.de \
--cc=siwu@hrz.tu-chemnitz.de \
--cc=sven.eckelmann@gmx.de \
--cc=tklauser@distanz.ch \
/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.