DPDK patches and discussions
 help / color / mirror / Atom feed
From: Panu Matilainen <pmatilai@redhat.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] config: default to shared library
Date: Wed, 04 Mar 2015 13:05:07 +0200	[thread overview]
Message-ID: <54F6E6E3.50404@redhat.com> (raw)
In-Reply-To: <1534932.rt5IAT3UZl@xps13>

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.

> 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 :)

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

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.

	- Panu -

  parent reply	other threads:[~2015-03-04 11:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04  6:17 Panu Matilainen
2015-03-04  9:24 ` Thomas Monjalon
2015-03-04 10:42   ` Bruce Richardson
2015-03-04 11:05   ` Panu Matilainen [this message]
2015-03-04 11:28     ` Neil Horman
2015-03-04 13:08       ` Bruce Richardson
2015-03-04 13:24         ` Panu Matilainen
2015-03-04 13:31           ` Bruce Richardson
2015-03-04 13:41             ` Panu Matilainen
2015-03-04 13:49               ` Bruce Richardson
2015-03-04 13:56                 ` Thomas Monjalon
2015-03-04 13:57                 ` David Marchand
2015-03-04 14:10                   ` Bruce Richardson
2015-03-04 11:29     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F6E6E3.50404@redhat.com \
    --to=pmatilai@redhat.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).