On 09.06.2015 00:09, Luis R. Rodriguez wrote: > On Thu, Jun 4, 2015 at 2:08 AM, Stefan Assmann <sassmann@xxxxxxxxx> wrote: >> On 03.06.2015 22:13, Hauke Mehrtens wrote: >>> Is it always save to just remove something which accesses skb->no_fcs in >>> all cases? I think sometimes some special handling for older kernel >>> version could be needed. This also looks very specific to the igb usage. >> >> In this case I'd say this is fine, no_fcs is used to send out frames with >> bad CRC for testing. So just commenting out related code shouldn't cause >> any harm. Yes, the cocci code is very specific and will likely need to be >> extended for other drivers when we pull them in. But you have to start >> somewhere. >> >> We always have the option to revert if something turns out to be a bad >> idea. > > I'm fine with merging now but please note the discussion, Hauke was > curious about the generality over the Coccinelle patch replacement > over a patch series. In order to help maintainers make a proper > assessment over whether or not we can merge an SmPL patch to replace a > patch series it is extremely useful to annotate the SmPL patch with > header comments which track: > > a) The respective upstream commit and kernel version which introduced > the collateral evolution for which you are generalizing > b) A good description which explains your understanding as to why this > should work and will not break run time > > a) is easy, b) is hard but it is the least we can do and I think we > will remain sane if we put this as a litmus test for future SmPL patch > replacements. Its not easy but please see my own SmPL patches and > review the description. Its pretty lengthy but these discussions can > be avoided if we had someone do the full homework. > > If we want to scale we need this. Are you folks OK with requiring a) > and b) on future SmPL patch replacements? Best effort at least. Keep > in mind reason for this is also I believe there are some further > generalizations we can reach if we follow these best practices which I > think will have further beneficial gains to us. Adding that info to the git commit log sounds like added value. I'll try to provide it in my next patchset. If I get you right, this is somewhat similar to what's in the INFO files, correct? Stefan -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
