Re: [dpdk-dev] [PATCH] config: default to shared library

[Bruce Richardson <bruce.richardson@intel.com>]

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?

/Bruce

> > 
> > I didn't want to make the commit message into a shared library sermon, but
> > if you look at the OSS landscape overall the common wisdom is that shared
> > library benefits outweigh any performance impact by so much that static libs
> > are almost nowhere to be found. I can change the text into a full-blown
> > rationale why shared libraries should be the default if that makes any
> > difference.
> > 
> Embedded applications actually do make extensive use of static linking to try
> achieve greater performance, but they tend to be proprietary, and as such are
> the exception that proves the rule.  Once an application itself becomes open
> source, it biases toward shared libraries, because the minor performance impact
> is well worth the increased manageability and security found in DSO's
> 
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> 
> > 	- Panu -
> > 
> >