From mboxrd@z Thu Jan  1 00:00:00 1970
From: Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [PATCH v2 01/18] eal: introduce dtor macros
Date: Thu, 22 Mar 2018 20:38:45 -0400
Message-ID: <20180323003844.GA16562@neilslaptop.think-freely.org>
References: <cover.1521652453.git.gaetan.rivet@6wind.com>
 <ec844df869b0bef9a4b64d07adae14ee35cbfa6a.1521652453.git.gaetan.rivet@6wind.com>
 <20180322135114.GB6272@hmswarspite.think-freely.org>
 <20180322155643.nrfkxosktvt67gik@bidouze.vm.6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: dev@dpdk.org
To: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id E25D05F4D
 for <dev@dpdk.org>; Fri, 23 Mar 2018 01:39:34 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <20180322155643.nrfkxosktvt67gik@bidouze.vm.6wind.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Thu, Mar 22, 2018 at 04:56:43PM +0100, Gaëtan Rivet wrote:
> On Thu, Mar 22, 2018 at 09:51:14AM -0400, Neil Horman wrote:
> > On Wed, Mar 21, 2018 at 06:15:22PM +0100, Gaetan Rivet wrote:
> > > Signed-off-by: Gaetan Rivet <gaetan.rivet@6wind.com>
> > > ---
> > >  lib/librte_eal/common/include/rte_common.h | 23 +++++++++++++++++++++++
> > >  1 file changed, 23 insertions(+)
> > > 
> > > diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
> > > index c7803e41c..500fc3adb 100644
> > > --- a/lib/librte_eal/common/include/rte_common.h
> > > +++ b/lib/librte_eal/common/include/rte_common.h
> > > @@ -105,6 +105,29 @@ static void __attribute__((constructor, used)) func(void)
> > >  static void __attribute__((constructor(prio), used)) func(void)
> > >  
> > >  /**
> > > + * Run after main() with high priority.
> > > + *
> > > + * The destructor will be run *before* prioritized destructors.
> > > + *
> > > + * @param func
> > > + *   Destructor function name.
> > > + */
> > > +#define RTE_FINI(func) \
> > > +static void __attribute__((destructor, used)) func(void)
> > > +
> > > +/**
> > > + * 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(prio), used)) func(void)
> > > +
> > > +/**
> > Additionally, it might be nice to further abstract the destructor priority to
> > fixed levels so that people aren't always trying to guess what the right magic
> > number should be.  I.e. create several destructor macros of the form:
> > RTE_FINI_<NAME>
> > 
> > Where name is a meaningfull term like FINAL, PMD, EARLY, or some such set that
> > implies a priority value encoded within the macro definition.  That would also
> > eliminate the need to create a BUILD BUG macro if the priority was specified to
> > be too low
> > 
> > Neil
> > 
> 
> Good idea, and I agree that we need helpers on this.
> Not sure about _FINAL and _EARLY however.
> 
Yeah, I don't like those either, but I couldn't think of any other priority
suffixes off the top of my head

FWIW, the kernel creates these macros to register initcalls:
#define pure_initcall(fn)               __define_initcall(fn, 0)
#define core_initcall(fn)               __define_initcall(fn, 1)
#define core_initcall_sync(fn)          __define_initcall(fn, 1s)
#define postcore_initcall(fn)           __define_initcall(fn, 2)
#define postcore_initcall_sync(fn)      __define_initcall(fn, 2s)
#define arch_initcall(fn)               __define_initcall(fn, 3)
#define arch_initcall_sync(fn)          __define_initcall(fn, 3s)
#define subsys_initcall(fn)             __define_initcall(fn, 4)
#define subsys_initcall_sync(fn)        __define_initcall(fn, 4s)
#define fs_initcall(fn)                 __define_initcall(fn, 5)
#define fs_initcall_sync(fn)            __define_initcall(fn, 5s)
#define rootfs_initcall(fn)             __define_initcall(fn, rootfs)
#define device_initcall(fn)             __define_initcall(fn, 6)
#define device_initcall_sync(fn)        __define_initcall(fn, 6s)
#define late_initcall(fn)               __define_initcall(fn, 7)
#define late_initcall_sync(fn)          __define_initcall(fn, 7s)

Its not an exact match, but you could probably borrow from that somewhat.

> I will propose a patch as a response to this mail, let me know if that's
> what you had in mind.
That was my hope yes, thanks!
Neil

> 
> -- 
> Gaëtan Rivet
> 6WIND
>