Re: [PATCH] config: default to shared library

[Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

2015-03-04 13:49, Bruce Richardson:
> 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! :-)

off-topic:
I think we should remove "#ifdef RTE_LIBRTE_IVSHMEM" in EAL and then remove
defconfig_x86_64-ivshmem-linuxapp-*.

> > >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.

+1 for x86_64-generic-linuxapp-gcc