From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Laatz, Kevin" Subject: Re: [PATCH v7 01/13] eal: add option register infrastructure Date: Wed, 24 Oct 2018 15:52:57 +0100 Message-ID: <217b61fe-e0bd-3acf-8306-2537c7d2f1c9@intel.com> References: <20181022110014.82153-1-kevin.laatz@intel.com> <20181024132725.5142-2-kevin.laatz@intel.com> <20181024140156.x4vyur6zxtbrrtny@bidouze.vm.6wind.com> <29630789.dO8WeQshWb@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?Q?Ga=c3=abtan_Rivet?= , dev@dpdk.org, harry.van.haaren@intel.com, stephen@networkplumber.org, shreyansh.jain@nxp.com, mattias.ronnblom@ericsson.com, bruce.richardson@intel.com To: Thomas Monjalon Return-path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 9D7354D27 for ; Wed, 24 Oct 2018 16:53:00 +0200 (CEST) In-Reply-To: <29630789.dO8WeQshWb@xps> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 24/10/2018 15:33, Thomas Monjalon wrote: > 24/10/2018 16:01, Gaƫtan Rivet: >> Hi Kevin, >> >> On Wed, Oct 24, 2018 at 02:27:13PM +0100, Kevin Laatz wrote: >>> This commit adds infrastructure to EAL that allows an application to >>> register it's init function with EAL. This allows libraries to be >>> initialized at the end of EAL init. >>> >>> This infrastructure allows libraries that depend on EAL to be initialized >>> as part of EAL init, removing circular dependency issues. >>> >>> Signed-off-by: Kevin Laatz >>> Acked-by: Harry van Haaren >> I think this is good enough, >> >> Acked-by: Gaetan Rivet > Yes it looks good enough. > And it compiles fine in my test. > >> The only remaining issue is rte_option_init(). >> Sorry I missed your previous message and did not respond in time, I >> would have opted for leaving a return value to at least be able to stop >> the init on error. It is possible to force the callback type to return >> an error value along with a string / hint describing the error. It >> should not be hard to add it later, so not blocking IMO. Agree this can be added in the future. > I think you need to set this API as experimental. Will do, thanks.