From: Luca Boccassi <bluca@debian.org>
To: Pallavi Kadam <pallavi.kadam@intel.com>, dev@dpdk.org
Cc: stephen@networkplumber.org
Subject: Re: [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 [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 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.