From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id B6F025B1C for ; Tue, 26 Mar 2019 15:40:56 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 07:40:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,271,1549958400"; d="scan'208";a="137405809" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by orsmga003.jf.intel.com with SMTP; 26 Mar 2019 07:40:50 -0700 Received: by (sSMTP sendmail emulation); Tue, 26 Mar 2019 14:40:48 +0000 Date: Tue, 26 Mar 2019 14:40:47 +0000 From: Bruce Richardson To: Jerin Jacob Kollanukkaran Cc: "pallavi.kadam@intel.com" , "thomas@monjalon.net" , "anand.rawat@intel.com" , "dev@dpdk.org" , "ranjit.menon@intel.com" , "jeffrey.b.shaw@intel.com" Message-ID: <20190326144047.GA472084@bricha3-MOBL.ger.corp.intel.com> References: <20190306041634.12976-1-anand.rawat@intel.com> <20190326060238.9884-1-anand.rawat@intel.com> <20190326060238.9884-4-anand.rawat@intel.com> <13f7c718448539712a6ba5024959b296143555e6.camel@marvell.com> <20190326105831.GA188340@bricha3-MOBL.ger.corp.intel.com> <5eeb911a2c8a3877f5ae110b88f56ba76df642de.camel@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5eeb911a2c8a3877f5ae110b88f56ba76df642de.camel@marvell.com> User-Agent: Mutt/1.11.2 (2019-01-07) Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file 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: Tue, 26 Mar 2019 14:40:57 -0000 On Tue, Mar 26, 2019 at 01:37:33PM +0000, Jerin Jacob Kollanukkaran wrote: > On Tue, 2019-03-26 at 10:58 +0000, Bruce Richardson wrote: > > ------------------------------------------------------------------- > > --- > > On Tue, Mar 26, 2019 at 10:32:34AM +0000, Jerin Jacob Kollanukkaran > > wrote: > > > On Mon, 2019-03-25 at 23:02 -0700, Anand Rawat wrote: > > > > adding a DEF file for kvargs to specify the exports > > > > for the creation of the shared library. > > > > > > > > Signed-off-by: Bruce Richardson > > > > Signed-off-by: Anand Rawat > > > > Reviewed-by: Pallavi Kadam > > > > Reviewed-by: Ranjit Menon > > > > --- > > > > lib/librte_kvargs/rte_kvargs_exports.def | 7 +++++++ > > > > 1 file changed, 7 insertions(+) > > > > create mode 100644 lib/librte_kvargs/rte_kvargs_exports.def > > > > > > > > diff --git a/lib/librte_kvargs/rte_kvargs_exports.def > > > > b/lib/librte_kvargs/rte_kvargs_exports.def > > > > new file mode 100644 > > > > index 000000000..265d3cc9a > > > > --- /dev/null > > > > +++ b/lib/librte_kvargs/rte_kvargs_exports.def > > > > > > Maintaining two separate files (.map and .def) for shared > > > library definition will be pain full. > > > > > > > Yes, though I'd question how much more painful it is than having to > > update > > a separate map file anyway - just consider the number of patches that > > It is painful due to the fact that, If it is windows ONLY file then > developer need to test on Windows as well as it may break Windows. > If it is a common file, at least, it will be tested on one platform. > So responsibly wise it is a clean partition between windows eal > maintainers vs generic library maintainers. > Yes, good point. However, once we get some windows support into the main repo then there is the requirement not to break that, so some testing on windows before merge will prove necessary. Hopefully that can be done just via CI, rather than having maintainers/committers do so manually. > > have been submitted over the years which failed shared library build > > because map file updates were forgotten. > > > > However, my hope is that down the road we can have the def file > > generated from the map file (or potentially vice versa). Perhaps the > > meson python module could be used to allow us to script it a bit. > > Make sense. Do we want to support shared lib for Windows for the first > version? or Can we live with static lib till we find a proper solution. > I do believe the base Windows Helloworld support needs to added this > release in main repo and add the subsequent features step by step. I > would treat, shared lib as subsequent feature if it is not clean. > Yes, I did consider that possibility. However, turning off shared builds for windows is more of a hack than adding a definition file, since it involves more (temporary) changes to the meson.build for both lib and driver. If I get the chance, I'll see how complicated it might be to autogenerate them at build. Otherwise, I'd suggest keeping the .def files for now, since only 2 libraries are involved, but then we need to come up with a proper solution before the number of libraries compiled on windows goes above that initial 2. /Bruce From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 9CCB9A05D3 for ; Tue, 26 Mar 2019 15:40:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 41EFB5F24; Tue, 26 Mar 2019 15:40:58 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id B6F025B1C for ; Tue, 26 Mar 2019 15:40:56 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2019 07:40:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,271,1549958400"; d="scan'208";a="137405809" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by orsmga003.jf.intel.com with SMTP; 26 Mar 2019 07:40:50 -0700 Received: by (sSMTP sendmail emulation); Tue, 26 Mar 2019 14:40:48 +0000 Date: Tue, 26 Mar 2019 14:40:47 +0000 From: Bruce Richardson To: Jerin Jacob Kollanukkaran Cc: "pallavi.kadam@intel.com" , "thomas@monjalon.net" , "anand.rawat@intel.com" , "dev@dpdk.org" , "ranjit.menon@intel.com" , "jeffrey.b.shaw@intel.com" Message-ID: <20190326144047.GA472084@bricha3-MOBL.ger.corp.intel.com> References: <20190306041634.12976-1-anand.rawat@intel.com> <20190326060238.9884-1-anand.rawat@intel.com> <20190326060238.9884-4-anand.rawat@intel.com> <13f7c718448539712a6ba5024959b296143555e6.camel@marvell.com> <20190326105831.GA188340@bricha3-MOBL.ger.corp.intel.com> <5eeb911a2c8a3877f5ae110b88f56ba76df642de.camel@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <5eeb911a2c8a3877f5ae110b88f56ba76df642de.camel@marvell.com> User-Agent: Mutt/1.11.2 (2019-01-07) Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190326144047.GNybOKw8lfqnjhBFRDYMhgm8fO8AD_xiK1lfPtaNCNY@z> On Tue, Mar 26, 2019 at 01:37:33PM +0000, Jerin Jacob Kollanukkaran wrote: > On Tue, 2019-03-26 at 10:58 +0000, Bruce Richardson wrote: > > ------------------------------------------------------------------- > > --- > > On Tue, Mar 26, 2019 at 10:32:34AM +0000, Jerin Jacob Kollanukkaran > > wrote: > > > On Mon, 2019-03-25 at 23:02 -0700, Anand Rawat wrote: > > > > adding a DEF file for kvargs to specify the exports > > > > for the creation of the shared library. > > > > > > > > Signed-off-by: Bruce Richardson > > > > Signed-off-by: Anand Rawat > > > > Reviewed-by: Pallavi Kadam > > > > Reviewed-by: Ranjit Menon > > > > --- > > > > lib/librte_kvargs/rte_kvargs_exports.def | 7 +++++++ > > > > 1 file changed, 7 insertions(+) > > > > create mode 100644 lib/librte_kvargs/rte_kvargs_exports.def > > > > > > > > diff --git a/lib/librte_kvargs/rte_kvargs_exports.def > > > > b/lib/librte_kvargs/rte_kvargs_exports.def > > > > new file mode 100644 > > > > index 000000000..265d3cc9a > > > > --- /dev/null > > > > +++ b/lib/librte_kvargs/rte_kvargs_exports.def > > > > > > Maintaining two separate files (.map and .def) for shared > > > library definition will be pain full. > > > > > > > Yes, though I'd question how much more painful it is than having to > > update > > a separate map file anyway - just consider the number of patches that > > It is painful due to the fact that, If it is windows ONLY file then > developer need to test on Windows as well as it may break Windows. > If it is a common file, at least, it will be tested on one platform. > So responsibly wise it is a clean partition between windows eal > maintainers vs generic library maintainers. > Yes, good point. However, once we get some windows support into the main repo then there is the requirement not to break that, so some testing on windows before merge will prove necessary. Hopefully that can be done just via CI, rather than having maintainers/committers do so manually. > > have been submitted over the years which failed shared library build > > because map file updates were forgotten. > > > > However, my hope is that down the road we can have the def file > > generated from the map file (or potentially vice versa). Perhaps the > > meson python module could be used to allow us to script it a bit. > > Make sense. Do we want to support shared lib for Windows for the first > version? or Can we live with static lib till we find a proper solution. > I do believe the base Windows Helloworld support needs to added this > release in main repo and add the subsequent features step by step. I > would treat, shared lib as subsequent feature if it is not clean. > Yes, I did consider that possibility. However, turning off shared builds for windows is more of a hack than adding a definition file, since it involves more (temporary) changes to the meson.build for both lib and driver. If I get the chance, I'll see how complicated it might be to autogenerate them at build. Otherwise, I'd suggest keeping the .def files for now, since only 2 libraries are involved, but then we need to come up with a proper solution before the number of libraries compiled on windows goes above that initial 2. /Bruce