From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9DA955683 for ; Wed, 4 Mar 2015 12:28:18 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YT7TD-0000lX-D1; Wed, 04 Mar 2015 06:28:14 -0500 Date: Wed, 4 Mar 2015 06:28:05 -0500 From: Neil Horman To: Panu Matilainen Message-ID: <20150304112805.GA5808@hmsreliant.think-freely.org> References: <1534932.rt5IAT3UZl@xps13> <54F6E6E3.50404@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F6E6E3.50404@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] config: default to shared library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 11:28:19 -0000 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. > > 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 > - Panu - > >