[PATCH v4 02/13] eal: replace strtok with reentrant version

[Stephen Hemminger]

On Tue, 29 Oct 2024 08:56:20 +0800
fengchengwen <fengchengwen at huawei.com> wrote:

> >>>
> >>> This doesn't need to go to stable. parse_params is always single threaded.    
> >>
> >> I recommend replacing all, based on:
> >> 1\ almost at no cost.
> >> 2\ reduce analysis costs, if don't we have to analyze the callers of strtok when you encounter it.
> >>  
> > 
> > Yes but. The replacement should not go to stable.
> > One of the rules of stable is that changes should be minimized, and fixes should
> > not be accepted for things that can not ever happen with current code.  
> 
> Hope more opinion from TB members.

My assumption is that DPDK operates under similar rules as the Linux kernel.
Linux kernel rules are:

Rules on what kind of patches are accepted, and which ones are not, into the “-stable” tree:
    • It or an equivalent fix must already exist in Linux mainline (upstream).
    • It must be obviously correct and tested.
    • It cannot be bigger than 100 lines, with context.
    • It must follow the Documentation/process/submitting-patches.rst rules.
    • It must either fix a real bug that bothers people or just add a device ID. To elaborate on the former:
        ◦ It fixes a problem like an oops, a hang, data corruption, a real security issue, a hardware quirk, a build error (but not for things marked CONFIG_BROKEN), or some “oh, that’s not good” issue.
        ◦ Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.
        ◦ No “This could be a problem...” type of things like a “theoretical race condition”, unless an explanation of how the bug can be exploited is also provided.
        ◦ No “trivial” fixes without benefit for users (spelling changes, whitespace cleanups, etc).