> -----Original Message----- > From: Van Haaren, Harry <[email protected]> > Sent: Wednesday, April 8, 2020 6:37 PM > To: Phil Yang <[email protected]>; [email protected]; Ananyev, > Konstantin <[email protected]>; > [email protected]; [email protected]; > [email protected] > Cc: [email protected]; [email protected]; > [email protected]; Honnappa Nagarahalli > <[email protected]>; Gavin Hu <[email protected]>; > Ruifeng Wang <[email protected]>; Joyce Kong > <[email protected]>; nd <[email protected]>; [email protected]; nd > <[email protected]> > Subject: RE: [PATCH v3 07/12] service: remove rte prefix from static functions > > > -----Original Message----- > > From: Phil Yang <[email protected]> > > Sent: Wednesday, April 8, 2020 11:15 AM > > To: Van Haaren, Harry <[email protected]>; > [email protected]; > > Ananyev, Konstantin <[email protected]>; > > [email protected]; [email protected]; > [email protected] > > Cc: [email protected]; [email protected]; > [email protected]; > > Honnappa Nagarahalli <[email protected]>; Gavin Hu > > <[email protected]>; Ruifeng Wang <[email protected]>; Joyce > Kong > > <[email protected]>; nd <[email protected]>; [email protected]; nd > <[email protected]> > > Subject: RE: [PATCH v3 07/12] service: remove rte prefix from static > functions > <snip> > > > Is this really a "Fix"? The internal function names were not exported > > > in the .map file, so are not part of public ABI. This is an internal > > > naming improvement (thanks for doing cleanup), but I don't think the > > > Fixes: tags make sense? > > > > > > Also I'm not sure if we want to port this patch back to stable? Changing > > > (internal) function names seems like unnecessary churn, and hence risk > to a > > > stable release, without any benefit? > > OK. > > I will remove these tags in the next version and split the service core > > patches from the original series into a series by itself. > > Cool - good idea to split. > > Perhaps we should focus on getting bugfixes in for the existing code, before > doing cleanup? It would make backports easier if churn is minimal. > > Suggesting patches order (first to last) > 1. bugfixes/things to backport > 2. cleanups > 3. C11 atomic optimizations
That is a good idea. I will follow this order. > > > > Thanks, > > Phil > > Thanks, and I'll get to reading/reviewing your and Honnappa's feedback later > today. > > -H
