From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: [PATCH] config: default to shared library Date: Wed, 04 Mar 2015 15:41:49 +0200 Message-ID: <54F70B9D.7040903@redhat.com> References: <1534932.rt5IAT3UZl@xps13> <54F6E6E3.50404@redhat.com> <20150304112805.GA5808@hmsreliant.think-freely.org> <20150304130848.GA544@bricha3-MOBL3> <54F7077C.1010504@redhat.com> <20150304133129.GB544@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Bruce Richardson Return-path: In-Reply-To: <20150304133129.GB544@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On 03/04/2015 03:31 PM, Bruce Richardson wrote: > On Wed, Mar 04, 2015 at 03:24:12PM +0200, Panu Matilainen wrote: >> On 03/04/2015 03:08 PM, Bruce Richardson wrote: >>> On Wed, Mar 04, 2015 at 06:28:05AM -0500, Neil Horman wrote: >>>> On Wed, Mar 04, 2015 at 01:05:07PM +0200, Panu Matilainen wrote: >>>>> On 03/04/2015 11:24 AM, Thomas Monjalon wrote: >>>>>> Hi Panu, >>>>>> >>>>>> 2015-03-04 08:17, Panu Matilainen: >>>>>>> With symbol versioning its vital that developers test their code in >>>>>>> shared library mode, otherwise we'll be playing "add the forgotten >>>>>>> symbol export" from here to eternity. >>>>>> >>>>>> Yes we must improve the sanity checks. >>>>>> A lot of options must be tested (or removed) and not only shared libs. >>>>>> But the error you reported before (missing export of rte_eth_dev_release_port) >>>>>> cannot be seen even with this patch. >>>>> >>>>> I know, I didn't say it would have directly caught it. It would've likely >>>>> been found earlier though, if nothing else then in testing of the new >>>>> librte_pmd_null which clearly nobody had tried in shared lib configuration. >>>>> >>>> This is accurate. The default config is a tool, in the sense that it leverages >>>> the implicit testing of any users who are experimenting with the DPDK. Any >>>> users out there using the DPDK test/example applications would have realized >>>> something was amiss when the testpmd app refused to run with the null or pcap >>>> pmd, since there was a missing symbol. That "social fuzzing" has value, but it >>>> only works if the defaults are carefully selected. Currently, building for >>>> shared libraries exposes more existing bugs than static libraries, and so we >>>> should set that as our default so as to catch them. >>>> >>>>>> It means we need more tools. >>>>>> Though, default configuration is not a tool. >>>>> >>>>> Yes, default config is not a tool, its a recommendation of sorts both for >>>>> developers and users. It also tends to be the setup that is rarely broken >>>>> because it happens to get the most testing :) >>>>> >>>> And it is a tool (see above). >>>> >>>>>> >>>>>>> By defaulting to shared we should catch more of these cases early, >>>>>>> but without taking away anybodys ability to build static. >>>>>> >>>>>> Shared libraries are convenient for distributions but have a performance >>>>>> impact. I think that static build must remain the default choice. >>>>> >>>> >>>> If utmost performance is the concern, isn't it reasonable to assume that users >>>> in that demographic will customize their configuration to achieve that? No one >>>> assumes that something is tuned to be perfect for their needs out of the box if >>>> their needs are extreemely biased to a single quality. The best course of >>>> action here is to set the default to be adventageous toward catching bugs, and >>>> document the changes needed to bias for performance. >>>> >>>>> For distros, this is not a matter of *convenience*, its the only technically >>>>> feasible choice. >>> >>> As I understand it, build for the "default" cpu rather than "native" is the only >>> feasible choice also, so how about re-introducing a new defconfig file for >>> "default" (or perhaps better name), where you have lowest-common denominator >>> instruction-set and building for shared libraries? >>> Would that work for everyone, or do people feel it would be too confusing to have >>> more defconfig files available? >> >> Given the opposition to defaulting to shared, another config file seems like >> a fair compromise to me, whether "default" or something else. As for the >> naming, one possibility would be calling it "shared", implying both >> lowest-common denominator instruction set to be shareable across many >> systems and shared libraries. >> >> - Panu - > > The naming scheme for configs is meant to be: > "ARCH-MACHINE-EXECENV-TOOLCHAIN" > as documented in the Getting Started Guide. "Default" has been used up till now > to refer to the lowest common denominator instruction set supported, which for > x86_64 is a core2 baseline, I believe. "shared" doesn't really fit into this > naming scheme, and there is nothing to allow extra notes to be added to the > name. Right, but then there's "ivshmem" that doesn't fit that description either AFAICS. > Without changing this scheme, I would suggest we rename "default" to "generic", > which I think is a slightly better term for it, and we set the > "x86_64-generic-linuxapp-gcc" target to build shared libs. Works for me. It is indeed more descriptive than either "default" or "shared" for the purpose. - Panu -