From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>
Subject: Re: [PATCH v10 05/27] eal: introduce dtor macros
Date: Tue, 10 Jul 2018 14:56:25 +0200
Message-ID: <20180710125625.4izywtqnex2rwdgf@bidouze.vm.6wind.com>
References: <cover.1530791217.git.gaetan.rivet@6wind.com>
 <42037d90036505fc764572b8a4c8b25a529c4ec7.1530791217.git.gaetan.rivet@6wind.com>
 <2903699.tLnOVabUjO@xps>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: dev@dpdk.org, shreyansh.jain@nxp.com
To: Thomas Monjalon <thomas@monjalon.net>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com
 [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id 8C2A14F9B
 for <dev@dpdk.org>; Tue, 10 Jul 2018 14:56:43 +0200 (CEST)
Received: by mail-wr1-f67.google.com with SMTP id t6-v6so14508908wrn.7
 for <dev@dpdk.org>; Tue, 10 Jul 2018 05:56:43 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <2903699.tLnOVabUjO@xps>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.rivet@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