From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH] config: default to shared library Date: Wed, 4 Mar 2015 13:49:11 +0000 Message-ID: <20150304134911.GC544@bricha3-MOBL3> 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> <54F70B9D.7040903@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev-VfR2kkLFssw@public.gmane.org To: Panu Matilainen Return-path: Content-Disposition: inline In-Reply-To: <54F70B9D.7040903-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 Wed, Mar 04, 2015 at 03:41:49PM +0200, Panu Matilainen wrote: > 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. Ah, yes, forgotten about that one! :-) > > >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 - >