From: Luca Boccassi <bluca@debian.org>
To: Pallavi Kadam <pallavi.kadam@intel.com>, dev@dpdk.org
Cc: stephen@networkplumber.org
Subject: Re: [dpdk-dev] [PATCH] helloworld: Windows DPDK sample application is compiled and built using eal and kvargs libraries in order to add windows support in the mainline repository.
Date: Fri, 30 Nov 2018 16:04:30 +0000 [thread overview]
Message-ID: <1543593870.18215.2.camel@debian.org> (raw)
In-Reply-To: <20181129050504.26996-1-pallavi.kadam@intel.com>
On Wed, 2018-11-28 at 21:05 -0800, Pallavi Kadam wrote:
> Signed-off-by: Pallavi Kadam <pallavi.kadam@intel.com>
> ---
> [RFC] This is a large patch that contains changes to build the
> HelloWorld
> sample application on Windows. It also contains changes to build the
> librte_eal and librte_kvargs libraries which are required to build
> the
> sample application. To merge these changes, this patch will be split
> up
> into multiple smaller patches and sent for review.
>
> lib/librte_eal/common/eal_common_errno.c | 9 +
> lib/librte_eal/common/eal_common_log.c | 2 +
> lib/librte_eal/common/eal_common_options.c | 2 +
> lib/librte_eal/common/eal_common_timer.c | 2 +
> .../common/include/arch/x86/rte_byteorder.h | 14 +
> .../common/include/arch/x86/rte_rtm.h | 22 +-
> lib/librte_eal/common/include/rte_common.h | 11 +
> .../common/include/rte_malloc_heap.h | 3 +
> lib/librte_eal/common/include/rte_random.h | 4 +
> .../common/include/rte_string_fns.h | 2 +
> lib/librte_eal/common/malloc_elem.h | 3 +
> lib/librte_eal/common/malloc_heap.c | 2 +
> lib/librte_eal/common/malloc_heap.h | 4 +
> lib/librte_eal/windows/eal/eal.c | 697 +++++++++
> lib/librte_eal/windows/eal/eal_alarm.c | 29 +
> lib/librte_eal/windows/eal/eal_debug.c | 102 ++
> lib/librte_eal/windows/eal/eal_fbarray.c | 1273
> +++++++++++++++++
> lib/librte_eal/windows/eal/eal_filesystem.h | 97 ++
> .../windows/eal/eal_hugepage_info.c | 20 +
> lib/librte_eal/windows/eal/eal_interrupts.c | 90 ++
> lib/librte_eal/windows/eal/eal_lcore.c | 83 ++
> lib/librte_eal/windows/eal/eal_log.c | 415 ++++++
> lib/librte_eal/windows/eal/eal_memalloc.c | 995 +++++++++++++
> lib/librte_eal/windows/eal/eal_memory.c | 140 ++
> lib/librte_eal/windows/eal/eal_proc.c | 1003 +++++++++++++
> lib/librte_eal/windows/eal/eal_thread.c | 167 +++
> lib/librte_eal/windows/eal/eal_timer.c | 40 +
> .../windows/eal/linux-emu/_rand48.c | 46 +
> .../windows/eal/linux-emu/drand48.c | 62 +
> lib/librte_eal/windows/eal/linux-emu/fork.c | 111 ++
> lib/librte_eal/windows/eal/linux-emu/getopt.c | 407 ++++++
> .../windows/eal/linux-emu/lrand48.c | 23 +
> lib/librte_eal/windows/eal/linux-emu/mman.c | 179 +++
> lib/librte_eal/windows/eal/linux-emu/setenv.c | 26 +
> .../windows/eal/linux-emu/srand48.c | 30 +
> .../windows/eal/linux-emu/termios.c | 11 +
> lib/librte_eal/windows/eal/linux-emu/unistd.c | 21 +
> lib/librte_eal/windows/eal/malloc_heap.c | 1068 ++++++++++++++
> lib/librte_eal/windows/eal/malloc_mp.c | 645 +++++++++
> .../windows/include_override/dirent.h | 950 ++++++++++++
> .../windows/include_override/getopt.h | 252 ++++
> .../windows/include_override/net/ethernet.h | 405 ++++++
> .../windows/include_override/netinet/in.h | 48 +
> .../windows/include_override/netinet/tcp.h | 4 +
> .../windows/include_override/pthread.h | 65 +
> .../windows/include_override/rand48.h | 32 +
> .../windows/include_override/sched.h | 21 +
> .../windows/include_override/sys/_iovec.h | 48 +
> .../include_override/sys/_sockaddr_storage.h | 54 +
> .../windows/include_override/sys/_termios.h | 222 +++
> .../windows/include_override/sys/_types.h | 105 ++
> .../windows/include_override/sys/cdefs.h | 3 +
> .../windows/include_override/sys/mman.h | 63 +
> .../include_override/sys/netbsd/queue.h | 846 +++++++++++
> .../windows/include_override/sys/queue.h | 11 +
> .../windows/include_override/syslog.h | 217 +++
> .../windows/include_override/termios.h | 1 +
> .../windows/include_override/unistd.h | 30 +
> .../windows/include_override/x86intrin.h | 1 +
> .../rte_override/exec-env/rte_interrupts.h | 3 +
> lib/librte_eal/windows/rte_override/rte_acl.h | 7 +
> .../windows/rte_override/rte_atomic.h | 744 ++++++++++
> .../windows/rte_override/rte_bus_pci.h | 25 +
> .../windows/rte_override/rte_byteorder.h | 10 +
> .../windows/rte_override/rte_common.h | 56 +
> .../windows/rte_override/rte_common.h.sav | 372 +++++
> .../windows/rte_override/rte_config.h | 328 +++++
> .../windows/rte_override/rte_cpuflags.h | 3 +
> .../windows/rte_override/rte_cycles.h | 26 +
> .../windows/rte_override/rte_debug.h | 22 +
> lib/librte_eal/windows/rte_override/rte_io.h | 8 +
> .../windows/rte_override/rte_lcore.h | 15 +
> .../windows/rte_override/rte_log.h.sav | 6 +
> .../windows/rte_override/rte_memcpy.h | 3 +
> .../windows/rte_override/rte_memory.h | 20 +
> .../windows/rte_override/rte_pause.h | 10 +
> lib/librte_eal/windows/rte_override/rte_pci.h | 7 +
> .../windows/rte_override/rte_per_lcore.h | 29 +
> .../windows/rte_override/rte_prefetch.h | 29 +
> lib/librte_eal/windows/rte_override/rte_rtm.h | 8 +
> .../windows/rte_override/rte_rwlock.h | 40 +
> .../windows/rte_override/rte_spinlock.h | 271 ++++
> .../windows/rte_override/rte_vect.h | 5 +
> .../windows/rte_override/rte_wincompat.h | 347 +++++
> .../windows/rte_override/rte_windows.h | 497 +++++++
> mk/exec-env/windows/DpdkRteLib.props | 46 +
> mk/exec-env/windows/dpdk.sln | 43 +
> .../windows/helloworld/helloworld.vcxproj | 98 ++
> .../helloworld/helloworld.vcxproj.filters | 22 +
> .../helloworld/helloworld.vcxproj.user | 4 +
> .../windows/librte_eal/librte_eal.vcxproj | 187 +++
> .../librte_eal/librte_eal.vcxproj.filters | 297 ++++
> .../librte_eal/librte_eal.vcxproj.user | 4 +
> .../librte_kvargs/librte_kvargs.vcxproj | 91 ++
> .../librte_kvargs.vcxproj.filters | 33 +
> .../librte_kvargs/librte_kvargs.vcxproj.user | 4 +
> 96 files changed, 14955 insertions(+), 3 deletions(-)
Hi,
In my (limited) experience managing cross-platform projects, having
manually defined Visual Studio files (*.vcxproj.*) manually checked in
git and maintained is always a pain. They invariably get out of sync
and rot, and they are massive and not very readable.
Given that we have now reasonably on-par support for Meson, which has
both a Visual Studio backend and a Ninja (which IIRC is supported by
VS) backend, wouldn't it be better to let the build be handled by Meson
itself? There might be a couple of places that needs fixing (we don't
always to the right thing of using join_path for directories for
example) but in the long run it would be much more maintainable IMHO.
Adding new libraries/PMDs would need to be done just once, etc etc.
--
Kind regards,
Luca Boccassi
prev parent reply other threads:[~2018-11-30 16:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 5:05 Pallavi Kadam
2018-11-29 18:15 ` Stephen Hemminger
2018-11-30 16:04 ` Luca Boccassi [this message]
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=1543593870.18215.2.camel@debian.org \
--to=bluca@debian.org \
--cc=dev@dpdk.org \
--cc=pallavi.kadam@intel.com \
--cc=stephen@networkplumber.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).