On 29/11/08 09:44, Michael Buesch wrote:
On Friday 28 November 2008 06:34:34 Shaddy Baddah wrote:
case the same simple function replacement would not be OK. But I saw
several places where memcmp() is preferred to compare_ether_addr(),
which I assume indicates that mac80211 does not expect alignment of
80211 packets passed to it.
The whole networking stack expects 4byte alignment and the driver _must_
make sure it is this way. Either by padding a constant number of bytes at the front
of each allocated SKB, or (if the alignment differs) use dynamic checks
for the lowest few bits of the pointer passed to mac80211.
Right. But I'm not sure that in this case that the packet is being
passed to mac80211 by the driver. My recall of the stack traces I saw
were that the unalignment I was seeing in sta_info_get() were a
consequence of transmission attempts.
I must admit though, I could not source where the unaligned packet came
from, as I do not fully understand the different queuing mechanisms in
use and where and how enqueues occur. My limited efforts to understand
this gave me the impression that network stack itself, and not the
driver, was constructing these unaligned packets, for transmission.
The memcmp() that really persuaded me to believe that the mac80211 had
no alignment requirements was this one:
net/mac80211/tx.c:1304: if (memcmp(odev->dev_addr, hdr->addr4,
ETH_ALEN) != 0)
I would have thought it would use compare_ether_addr() if we could
safely assume alignment. In any case, say that alignment was always the
intention... then can't we just use memcmp() as a hack (not being
derogatory. Just that it would turn into a hack in deference to using
compare_ether_addr()) consistent with hacks like the above? Even in the
interim until a program to iron out alignment is set in place?
Regards,
Shaddy
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
