DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gaëtan Rivet" <grive@u256.net>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] bus/pci: cleanup private symbols
Date: Wed, 6 May 2020 19:21:23 +0200	[thread overview]
Message-ID: <20200506172123.w37j737azn7ijdxa@u256.net> (raw)
In-Reply-To: <20200506124314.14009-2-david.marchand@redhat.com>

On 06/05/20 14:43 +0200, David Marchand wrote:
> Internal symbols do not need the rte_ prefix.
> Some symbols do not need to be exposed in the private header and have
> been made static.
> 
> Fixes: c752998b5e2e ("pci: introduce library and driver")
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>

For this patch, I would like to understand why we are having this
policy. Symbols that are emitted for later linking will be present in
archives generated by the framework. Am I wrong to think they can
conflict with user app symbols?

If that is correct, we should use pci_* prefix for static symbols,
rte_* for everything else, even "internal" symbols -- in the sense
that they are meant to be opaque to the user, but will still be linked
in static build.

If I'm wrong in thinking this, then ok with this policy and let's go
forward to align naming in PCI bus.

-- 
Gaëtan

  reply	other threads:[~2020-05-06 17:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 12:43 [dpdk-dev] [PATCH 1/2] remove references to private PCI probe function David Marchand
2020-05-06 12:43 ` [dpdk-dev] [PATCH 2/2] bus/pci: cleanup private symbols David Marchand
2020-05-06 17:21   ` Gaëtan Rivet [this message]
2020-05-06 20:25     ` Stephen Hemminger
2020-05-07 12:43       ` David Marchand
2020-05-07 12:41     ` David Marchand
2020-05-06 14:05 ` [dpdk-dev] [PATCH 1/2] remove references to private PCI probe function Gaëtan Rivet
2020-05-11 14:56 ` David Marchand

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=20200506172123.w37j737azn7ijdxa@u256.net \
    --to=grive@u256.net \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    /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).