27/02/2021 21:23, Dmitry Kozlyuk:
> 2021-02-23 09:45, Bruce Richardson:
> > On Tue, Feb 23, 2021 at 01:57:50AM +0300, Dmitry Kozlyuk wrote:
> > > 2021-02-22 14:26, Bruce Richardson:
> > > > As you say, though, the main issue will be whether we have instances in
> > > > public header files or not.
DPDK supports a variety of platforms and toolsets and my experience with
SPDK suggests that we'll end up with compiler specific ifdef's.
I'd argue they are inevitable. Consider POSIX close(): if it's missing, what
would be a correct fallback? It depends on the execution environment (OS).
Str
2021-03-01 21:31, Nick Connolly:
> > There's a meson issue with `cc.has_function()`:
> > https://github.com/mesonbuild/meson/issues/5628
> >
> > What if we just define RTE_INTERNAL for librte_eal/windows/include/rte_os.h
> > (and other public headers if need be) to distinguish the case when it's us
There's a meson issue with `cc.has_function()`:
https://github.com/mesonbuild/meson/issues/5628
What if we just define RTE_INTERNAL for librte_eal/windows/include/rte_os.h
(and other public headers if need be) to distinguish the case when it's used
from within DPDK?
It's a pragmatic solution t
2021-02-23 09:45, Bruce Richardson:
> On Tue, Feb 23, 2021 at 01:57:50AM +0300, Dmitry Kozlyuk wrote:
> > 2021-02-22 14:26, Bruce Richardson:
> > > As you say, though, the main issue will be whether we have instances in
> > > public header files or not. I would hope that no static inline function
On Tue, Feb 23, 2021 at 01:57:50AM +0300, Dmitry Kozlyuk wrote:
> 2021-02-22 14:26, Bruce Richardson:
> > As you say, though, the main issue will be whether we have instances in
> > public header files or not. I would hope that no static inline functions in
> > DPDK use any of the functions in ques
2021-02-22 14:26, Bruce Richardson:
> As you say, though, the main issue will be whether we have instances in
> public header files or not. I would hope that no static inline functions in
> DPDK use any of the functions in question, but I'm not sure. Perhaps if
> there are instances in public heade
There seem to be two viable approaches to handling this:
1. Expect the platform to provide POSIX semantic (through an external
...
I'd prefer not to see this be a requirement of the platform. There have
been multiple attempts over the years to provide a POSIX surfaces
on Windows which arg
For any functions, such as strdup, which are not in a public header I would
suggest the following as a possible start point, based off what was done
for strlcpy.
* In DPDK (probably EAL), define an rte_strdup function for use as a
fallback.
* Inside the meson build scripts, use "cc.has_func
On Mon, Feb 22, 2021 at 12:48:39PM +, Nick Connolly wrote:
>
> There seem to be two viable approaches to handling this:
>
> 1. Expect the platform to provide POSIX semantic (through an external
>library
>such as Cygwin). That way it becomes "an 'external' problem" and the
>DPDK
>
On Mon, Feb 22, 2021 at 12:48:39PM +, Nick Connolly wrote:
> Rather than defining "rte_" versions of these functions, is it possible
> just to provide the unprefixed definitions of them for internal use?
> While this probably won't work for any functions used in public headers,
> for any functi
Rather than defining "rte_" versions of these functions, is it possible
just to provide the unprefixed definitions of them for internal use?
While this probably won't work for any functions used in public headers,
for any functions only used in C files, we can use meson to detect the
presence o
On Sun, Feb 21, 2021 at 04:28:25AM +0300, Dmitry Kozlyuk wrote:
> POSIX strncasecmp(), strdup(), and strtok_r() have different names
> on Windows, respectively, strnicmp(), _strdup(), and strtok_s().
>
> Add wrappers as inline functions, because they're used from librte_kvargs,
> and thus cannot b
POSIX strncasecmp(), strdup(), and strtok_r() have different names
on Windows, respectively, strnicmp(), _strdup(), and strtok_s().
Add wrappers as inline functions, because they're used from librte_kvargs,
and thus cannot be in librte_eal; besides, implementation is trivial.
Signed-off-by: Dmitr
14 matches
Mail list logo
