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