From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id E25D05F4D for ; Fri, 23 Mar 2018 01:39:34 +0100 (CET) Received: from cpe-2606-a000-111b-40b7-215-ff-fecc-4872.dyn6.twc.com ([2606:a000:111b:40b7:215:ff:fecc:4872] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ezAjo-0002tc-OI; Thu, 22 Mar 2018 20:39:33 -0400 Date: Thu, 22 Mar 2018 20:38:45 -0400 From: Neil Horman To: =?iso-8859-1?Q?Ga=EBtan?= Rivet Cc: dev@dpdk.org Message-ID: <20180323003844.GA16562@neilslaptop.think-freely.org> References: <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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180322155643.nrfkxosktvt67gik@bidouze.vm.6wind.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH v2 01/18] eal: introduce dtor macros X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 00:39:35 -0000 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 > > > --- > > > 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_ > > > > 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 >