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 <nhor...@tuxdriver.com> 
> Sent: Monday, June 1, 2020 12:56 PM
> To: Fady Bader <f...@mellanox.com>
> Cc: dev@dpdk.org; tho...@monjalon.net; tbas...@mellanox.com; 
> tal...@mellanox.com; yoh...@mellanox.com; dmitry.kozl...@gmail.com; Harini 
> Ramakrishnan <harini.ramakrish...@microsoft.com>; Omar Cardona 
> <ocard...@microsoft.com>; pallavi.ka...@intel.com; ranjit.me...@intel.com; 
> olivier.m...@6wind.com; arybche...@solarflare.com; m...@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 <f...@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
> > 
> > 
> 

Reply via email to