November 4, 2026 at 7:40 PM, "Thomas Monjalon" <[email protected] mailto:[email protected]?to=%22Thomas%20Monjalon%22%20%3Cthomas%40monjalon.net%3E > wrote:
> > 04/11/2026 10:29, David Marchand: > > > > > On Wed, 4 Nov 2026 at 09:56, fengchengwen <[email protected]> wrote: > > On 11/4/2026 3:34 PM, Stephen Hemminger wrote: > > >> From: Chengwen Feng <[email protected]> > > >> 905 files changed, 6113 insertions(+), 5439 deletions(-) > > > > > > Maybe a single coccinelle script would help here? Rather than trying to > > look > > > at so many patches. > > > > A coccinelle script is a helpful idea. I will try to prepare one. > > > > Well, maybe. > > But never a 200+ patches series again. > > > > Putting aside the way it was submitted, it seems this change is only > > cosmetic, and it was not announced in a *previous* deprecation notice. > > > > Why do we need this change? > > Why now, in this release? > > > I assume it is not for 26.11. > Chengwen wanted to fix the namespace of SOCKET_ID_ANY, adding RTE_. > And I told him that we should avoid changing this API 2 times > when we will want to fix the terminology > around CPU socket and NUMA memory domain. > I think we should do both at once. > That's why we see this big change. > > BUT > > It would be more efficient for such a change to discuss it first. > Then once we agree on the names and usage, > we should make it in a way it can be reproduced, maintained > and ease future backport of patches containing the new terminology. > A coccinelle script looks appropriate. > And of course, the patch series should not have so many patches, > it does not make sense. > A mechanical change should come in one patch. > If the series deserves several different mechanical changes, > few patches should be sent for them, not hundreds. > Thanks Thomas for explaining the background of this change. This series was AI-generated following the one commit per moduleconvention to support per-subsystem review, with the expectationthat these commits would be squashed before merge. I understand this split imposed heavy CI load now, and I will adjustthe patch organisation in the next version. Moving forward, I will prepare a coccinelle script for the mechanicalconversion and follow the deprecation process before formal submission.
