On Mon, 14 Sep 2015, Luis R. Rodriguez wrote: > On Mon, Sep 14, 2015 at 1:27 AM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 2015-09-14 at 01:25 -0700, Luis R. Rodriguez wrote: > > > >> > ++#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,3,0) > >> > + E->priv_flags |= IFF_NO_QUEUE; > >> > ++#else > >> > ++E->tx_queue_len = 0; > >> > ++#endif > >> > >> Interesting so although priv_flags may be a member name prevalent in > >> *many* data structures the SmPL rule here is very specific about the > >> use of IFF_NO_QUEUE as a flag, and since we know that is unique to one > >> use case we take the liberty over using expression here. Replying just > >> to annotate this practice and Cc Julia on her thoughts. > >> > > > > Yeah I thought about this for a while - it doesn't even cover all cases > > (there might be drivers that don't use |=, for example). > > > > However, for now this seemed sufficient since very few places in the > > code actually use this. > > Sure, I wonder we could use some early rule checks to catch some > liberal assumptions we make for some of our rules in patches/, we > would use that to report issues *prior* to patch application and we'd > reject moving forward with generation if all these rule checks don't > match. If we do this that would stop patch application / compilation > testing proactively. Something as with the kernel's > scripts/coccinelle/ 'make coccicheck' prior to running our patch > application. This case seems a bit hard to cover for all cases that > don't use the assignments as in your rule though I think... if its > easy though it could be a good example to tackle. I'm not sure to understand what you have in mind. Could you be more concrete? julia > > > That said, there are cases where E really needs to be an expression > > since it's not just "dev->..." but something like "foo->dev->...". > > Right figured. > > Luis > -- To unsubscribe from this list: send the line "unsubscribe backports" in