DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kinsella, Ray" <mdr@ashroe.eu>
To: Thomas Monjalon <thomas@monjalon.net>,
	Omar Cardona <ocardona@microsoft.com>,
	Neil Horman <nhorman@tuxdriver.com>
Cc: Fady Bader <fady@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>,
	"tbashar@mellanox.com" <tbashar@mellanox.com>,
	"talshn@mellanox.com" <talshn@mellanox.com>,
	"yohadt@mellanox.com" <yohadt@mellanox.com>,
	"dmitry.kozliuk@gmail.com" <dmitry.kozliuk@gmail.com>,
	Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>,
	"pallavi.kadam@intel.com" <pallavi.kadam@intel.com>,
	"ranjit.menon@intel.com" <ranjit.menon@intel.com>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>
Subject: Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
Date: Thu, 11 Jun 2020 11:09:00 +0100
Message-ID: <3c311ebd-a722-a98f-6766-b0cfd0d2695c@ashroe.eu> (raw)
In-Reply-To: <2183772.jD3h1DLmXV@thomas>

So apologies for resurrecting an old thread - I did want to chime on this.

From a past life as a Windows Programmer, I would say that shared libraries model on Windows is not as strong as on Linux/Unix.
Libraries on Windows are typically packaged and distributed along with the applications, not usually at a system level as in Linux/Unix.

That said - I strongly agree with Omar - that does not mean that stable ABI's should not be goal on Windows.
This does not diminish the value of enabling Windows applications to seamless upgrade their DPDK, at an application level.

So I don't have a problem with disabling function-level versioning as an interim measure, until we figure out the best mechanism.
What I would suggest is that we aim to get this sort for the v22 ABI in the 21.11 release.
And that we clearly indicate in v21 in 20.11 that Windows is not yet covered in the ABI policy.

Make sense?

Ray K

On 02/06/2020 11:40, Thomas Monjalon wrote:
> 02/06/2020 12:27, Neil Horman:
>> On Mon, Jun 01, 2020 at 09:46:18PM +0000, Omar Cardona wrote:
>>>>> Do we know if we have future plans of supporting dlls on windows in the future?
>>> 	- Hi Neil, yes this is of interest to us (Windows).  
>>> 	- Specifically to aid in non-disruptive granular servicing/updating.
>>> 	- Our primary scenario Userspace VMSwitch is biased towards shared libraries for production servicing
>> Ok, do you have recommendations on how to provide backwards compatibility
>> between dpdk versions?  From what I read the most direct solution would be
>> per-application dll bundling (which seems to me to defeat the purpose of
>> creating a dll, but if its the only solution, perhaps thats all we have to work
>> with).  Is there a better solution?
>> If not, then I would suggest that, instead of disabling shared libraries on
>> Windows, as we do below, we allow it, and redefine VERSION_SYMBOL[_EXPERIMENTAL]
>> to do nothing, and implement BIND_DEFAULT_SYMBOL to act like MAP_STATIC_SYMBOL
>> by aliasing the supplied symbol name to the provided export name.  I think msvc
>> supports aliasing, correct?
> We don't use msvc, but clang and MinGW.

  reply	other threads:[~2020-06-11 10:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-01 10:31 [dpdk-dev] [PATCH v2 0/4] build mempool " Fady Bader
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning " Fady Bader
2020-06-01 19:55   ` Neil Horman
2020-06-01 21:46     ` [dpdk-dev] [EXTERNAL] " Omar Cardona
2020-06-02 10:27       ` Neil Horman
2020-06-02 10:40         ` Thomas Monjalon
2020-06-11 10:09           ` Kinsella, Ray [this message]
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management Fady Bader
2020-06-01 19:59   ` Dmitry Kozlyuk
2020-06-01 20:47     ` Ranjit Menon
2020-06-01 21:14     ` Thomas Monjalon
2020-06-02  7:40       ` Andrew Rybchenko
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 3/4] eal: export needed functions for mempool Fady Bader
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows Fady Bader
2020-06-02  7:41   ` Andrew Rybchenko

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:

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

  git send-email \
    --in-reply-to=3c311ebd-a722-a98f-6766-b0cfd0d2695c@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=Harini.Ramakrishnan@microsoft.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=fady@mellanox.com \
    --cc=nhorman@tuxdriver.com \
    --cc=ocardona@microsoft.com \
    --cc=olivier.matz@6wind.com \
    --cc=pallavi.kadam@intel.com \
    --cc=ranjit.menon@intel.com \
    --cc=talshn@mellanox.com \
    --cc=tbashar@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=yohadt@mellanox.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git