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. > 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
