diff mbox series

[v2,1/4] eal: disable function versioning on Windows

Message ID 20200601103139.8612-2-fady@mellanox.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series build mempool on Windows |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation fail apply issues

Commit Message

Fady Bader June 1, 2020, 10:31 a.m. UTC 
  Function versioning is not needed on Windows, also the function versioning
implementation is not supported by Windows.
Function versioning was disabled on Windows.

Signed-off-by: Fady Bader <fady@mellanox.com>
---
 lib/librte_eal/include/rte_function_versioning.h | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Neil Horman June 1, 2020, 7:55 p.m. UTC | #1 
On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> Function versioning is not needed on Windows, also the function versioning
> implementation is not supported by Windows.
> Function versioning was disabled on Windows.
> 
I get that windows doesn't seem to support symbol level versioning, but I'm not
sure its reasonable to say that its not needed, unless we never have any
intention of building dpdk on windows using a DSO model.  The below definately
solves the immediate problem, but if we plan to support windows with dynamic
library builds, this just kicks the can down the road.

Do we know if we have future plans of supporting dlls on windows in the future?

Neil

> Signed-off-by: Fady Bader <fady@mellanox.com>
> ---
>  lib/librte_eal/include/rte_function_versioning.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/librte_eal/include/rte_function_versioning.h b/lib/librte_eal/include/rte_function_versioning.h
> index f588f2643..cee06602e 100644
> --- a/lib/librte_eal/include/rte_function_versioning.h
> +++ b/lib/librte_eal/include/rte_function_versioning.h
> @@ -11,6 +11,10 @@
>  #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
>  #endif
>  
> +#ifdef RTE_EXEC_ENV_WINDOWS
> +#undef RTE_BUILD_SHARED_LIB
> +#endif
> +
>  #ifdef RTE_BUILD_SHARED_LIB
>  
>  /*
> -- 
> 2.16.1.windows.4
> 
>
Omar Cardona June 1, 2020, 9:46 p.m. UTC | #2 
>> 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


-----Original Message-----
From: Neil Horman <nhorman@tuxdriver.com> 
Sent: Monday, June 1, 2020 12:56 PM
To: Fady Bader <fady@mellanox.com>
Cc: dev@dpdk.org; thomas@monjalon.net; tbashar@mellanox.com; talshn@mellanox.com; yohadt@mellanox.com; dmitry.kozliuk@gmail.com; Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>; Omar Cardona <ocardona@microsoft.com>; pallavi.kadam@intel.com; ranjit.menon@intel.com; olivier.matz@6wind.com; arybchenko@solarflare.com; mdr@ashroe.eu
Subject: [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows

On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> Function versioning is not needed on Windows, also the function 
> versioning implementation is not supported by Windows.
> Function versioning was disabled on Windows.
> 
I get that windows doesn't seem to support symbol level versioning, but I'm not sure its reasonable to say that its not needed, unless we never have any intention of building dpdk on windows using a DSO model.  The below definately solves the immediate problem, but if we plan to support windows with dynamic library builds, this just kicks the can down the road.

Do we know if we have future plans of supporting dlls on windows in the future?

Neil

> Signed-off-by: Fady Bader <fady@mellanox.com>
> ---
>  lib/librte_eal/include/rte_function_versioning.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/librte_eal/include/rte_function_versioning.h 
> b/lib/librte_eal/include/rte_function_versioning.h
> index f588f2643..cee06602e 100644
> --- a/lib/librte_eal/include/rte_function_versioning.h
> +++ b/lib/librte_eal/include/rte_function_versioning.h
> @@ -11,6 +11,10 @@
>  #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
>  #endif
>  
> +#ifdef RTE_EXEC_ENV_WINDOWS
> +#undef RTE_BUILD_SHARED_LIB
> +#endif
> +
>  #ifdef RTE_BUILD_SHARED_LIB
>  
>  /*
> --
> 2.16.1.windows.4
> 
>
Neil Horman June 2, 2020, 10:27 a.m. UTC | #3 
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?
Neil

> 
> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com> 
> Sent: Monday, June 1, 2020 12:56 PM
> To: Fady Bader <fady@mellanox.com>
> Cc: dev@dpdk.org; thomas@monjalon.net; tbashar@mellanox.com; talshn@mellanox.com; yohadt@mellanox.com; dmitry.kozliuk@gmail.com; Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>; Omar Cardona <ocardona@microsoft.com>; pallavi.kadam@intel.com; ranjit.menon@intel.com; olivier.matz@6wind.com; arybchenko@solarflare.com; mdr@ashroe.eu
> Subject: [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
> 
> On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> > Function versioning is not needed on Windows, also the function 
> > versioning implementation is not supported by Windows.
> > Function versioning was disabled on Windows.
> > 
> I get that windows doesn't seem to support symbol level versioning, but I'm not sure its reasonable to say that its not needed, unless we never have any intention of building dpdk on windows using a DSO model.  The below definately solves the immediate problem, but if we plan to support windows with dynamic library builds, this just kicks the can down the road.
> 
> Do we know if we have future plans of supporting dlls on windows in the future?
> 
> Neil
> 
> > Signed-off-by: Fady Bader <fady@mellanox.com>
> > ---
> >  lib/librte_eal/include/rte_function_versioning.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/lib/librte_eal/include/rte_function_versioning.h 
> > b/lib/librte_eal/include/rte_function_versioning.h
> > index f588f2643..cee06602e 100644
> > --- a/lib/librte_eal/include/rte_function_versioning.h
> > +++ b/lib/librte_eal/include/rte_function_versioning.h
> > @@ -11,6 +11,10 @@
> >  #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
> >  #endif
> >  
> > +#ifdef RTE_EXEC_ENV_WINDOWS
> > +#undef RTE_BUILD_SHARED_LIB
> > +#endif
> > +
> >  #ifdef RTE_BUILD_SHARED_LIB
> >  
> >  /*
> > --
> > 2.16.1.windows.4
> > 
> > 
>
Thomas Monjalon June 2, 2020, 10:40 a.m. UTC | #4 
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.
Ray Kinsella June 11, 2020, 10:09 a.m. UTC | #5 
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.
>
>
diff mbox series

Patch

diff --git a/lib/librte_eal/include/rte_function_versioning.h b/lib/librte_eal/include/rte_function_versioning.h
index f588f2643..cee06602e 100644
--- a/lib/librte_eal/include/rte_function_versioning.h
+++ b/lib/librte_eal/include/rte_function_versioning.h
@@ -11,6 +11,10 @@ 
 #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
 #endif
 
+#ifdef RTE_EXEC_ENV_WINDOWS
+#undef RTE_BUILD_SHARED_LIB
+#endif
+
 #ifdef RTE_BUILD_SHARED_LIB
 
 /*