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