Hi Thomas, On Tue, Jul 10, 2018 at 01:40:01PM +0200, Thomas Monjalon wrote: > 05/07/2018 13:48, Gaetan Rivet: > > Signed-off-by: Gaetan Rivet <gaetan.ri...@6wind.com> > > Please justify why you need destructors, by providing a commit log. > > > --- a/lib/librte_eal/common/include/rte_common.h > > +++ b/lib/librte_eal/common/include/rte_common.h > > @@ -111,6 +111,29 @@ static void > > __attribute__((constructor(RTE_PRIO(prio)), used)) func(void) > > #define RTE_INIT(func) \ > > RTE_INIT_PRIO(func, LAST) > > > > +/** > > + * Run after main() with low priority. > > + * > > + * @param func > > + * Destructor function name. > > + * @param prio > > + * Priority number must be above 100. > > + * Lowest number is the last to run. > > + */ > > +#define RTE_FINI_PRIO(func, prio) \ > > +static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void) > > I don't like the name of this macro. > What about RTE_CLEAN_PRIO? > >
FINI is symmetrical to INIT in referencing the related ELF section. RTE_CLEAN presumes that the intended purpose of the function will be to cleanup resources. As far as we are concerned, this code could send a signal, dump config info or format / (which would be a pretty advanced cleanup, granted). Sometimes, it could be used to release resources, presumably. I'm not a fan of FINI either, but I appreciate the symmetry. It's pretty neutral about what it does, as its meaning is literally "The following function will be part of the .fini section". Alternatives: FINALIZE UNINIT But they have the same issue as RTE_CLEAN, IMO. -- Gaëtan Rivet 6WIND
