Thread (25 messages) flat view 25 messages, 9 authors, 2014-01-17

Re: [PATCH 4/11] use ether_addr_equal_64bits

From: Emmanuel Grumbach <hidden>
Date: 2013-12-31 06:26:51
Also in: kernel-janitors, linux-wireless, lkml

On Tue, Dec 31, 2013 at 1:13 AM, Johannes Berg
[off-list ref] wrote:
On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
quoted
On Mon, 30 Dec 2013, Johannes Berg wrote:
quoted
On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
quoted
quoted
Is there any way we could catch (sparse, or some other script?) that
struct reorganising won't break the condition needed ("within a
structure that contains at least two more bytes")?
What kind of reorganizing could happen?  Do you mean that the programmer
might do at some time in the future, or something the compiler might do?
I'm just thinking of a programmer, e.g. changing a struct like this:

 struct foo {
   u8 addr[ETH_ALEN];
-  u16 dummy;
 };

for example.
That is easily resolved by:

struct foo {
      u8 addr[ETH_ALEN];
      u16 required_padding;   /* do not remove upon pain of death */
};
That'd be a stupid waste of struct space. If anything, there should be
*only* a comment saying that at least two bytes are needed - I'd still
prefer an automated check.
Frankly I am not sure I like the patch. This flow is not a fast path
at all. While I don't really care for the waste in iwlwifi (because
there isn't), I don't see the real point is make the code more
sensitive to changes to earn basically nothing.

This flow happens only upon association which means a few times an hour maybe...
The only advantage I see here is that people like me who don't always
have a chance to read / write much code outside their little tiny
boring driver get to know about this kind of things. So, from an
educational point of view - this is cool.
But education is one thing, and the code is another.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help