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 -
