From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v10 05/27] eal: introduce dtor macros
Date: Tue, 10 Jul 2018 15:06:59 +0200
Message-ID: <13825708.2VSpJNBVIU@xps>
References: <cover.1530791217.git.gaetan.rivet@6wind.com>
 <2903699.tLnOVabUjO@xps>
 <20180710125625.4izywtqnex2rwdgf@bidouze.vm.6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dev@dpdk.org, shreyansh.jain@nxp.com
To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com
 [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 676861B152
 for <dev@dpdk.org>; Tue, 10 Jul 2018 15:07:05 +0200 (CEST)
In-Reply-To: <20180710125625.4izywtqnex2rwdgf@bidouze.vm.6wind.com>
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>

10/07/2018 14:56, Ga=EBtan Rivet:
> Hi Thomas,
>=20
> 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>
> >=20
> > Please justify why you need destructors, by providing a commit log.
> >=20
> > > --- 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)
> > > =20
> > > +/**
> > > + * 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(v=
oid)
> >=20
> > I don't like the name of this macro.
> > What about RTE_CLEAN_PRIO?
> >=20
> >=20
>=20
> FINI is symmetrical to INIT in referencing the related ELF section.
>=20
> 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).
>=20
> Sometimes, it could be used to release resources, presumably.
>=20
> 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".
>=20
> Alternatives:
>=20
>    FINALIZE
>    UNINIT
>=20
> But they have the same issue as RTE_CLEAN, IMO.

OK, you convinced me. And I remember now that you already convinced
me earlier with the same argument :)

Acked-by: Thomas Monjalon <thomas@monjalon.net>