Re: [PATCH 1/4] backports: replace igb skb->no_fcs patch with semantic patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux