Guys, thank you for the info so far (sorry about the HTML thing).
I will put some further insight/closure into this thread.
So, my query started from the fact that when developing a new EAL in DPDK using an
external toolchain and/or for a new OS, the "common" (generic) part of the EAL
is actually Linux/BSD bound:
/...// START OF EXCERPT////dpdk/build/include/rte_eal.h:15:19: fatal error: sched.h: No such file
or directory////#include <sched.h>////^////compilation terminated.////...// END OF EXCERPT///
Above I'm building (via cross toolchain) my new "xyzapp" (with its own EAL
rte_*.c files) but with the inherited common headers (since the EAL/common master
Makefile makes build-generated symbolic links in my build dir).
So for now, I identified two quick options:
- Modify the EAL headers where needed. In this case, I would remove includes
such as ones above from the EAL headers, but it would probably break current
supported EALs
- Modify the EAL build sub-system to export my "xyzapp" (re)implemented EAL headers
instead of the common ones (keeping the API, but fixing the "app" toolchain/exec-env
dependencies).
Basically all P headers that define the EAL would be split into M "common/generic"
headers and N "app" re-implemented headers.
Thank you!
Alex
On 22-May-18 11:18 PM, Thomas Monjalon wrote:
22/05/2018 21:59, Wiles, Keith:
You may want to do an RFC email subject to discuss your ideas on changing EAL
code first to eliminate extra work.
Yes, definitely, RFC with first ideas can help to discuss.
One more pointer, Windows support in progress:
http://dpdk.org/browse/draft/dpdk-draft-windows/
