On Tue, 29 Oct 2024 08:56:20 +0800
fengchengwen <fengcheng...@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).
