On May 22, 2018, at 2:23 PM, Alexandru Ciobotaru <alex.ciobot...@gmail.com<mailto:alex.ciobot...@gmail.com>> wrote:
Greetings, I can not answer all of your questions, but maybe a few. I'm currently checking on how to add new EAL "app" to the DPDK so I started by adding a new "xyzapp" next to "linuxapp" and "bsdapp". Now, I would probably expect to make this new EAL mainline compliant on day, and to avoid future headaches, the plan is to avoid modifying things outside of my "xyzapp". And thus, the first adaptation issue has arrived: EAL is designed so that I can re-implement the "common" source files into my "xyzapp" but how would I override the "include/rte_xyz.h" headers from the "common" part of the EAL library (e.g. librte_eal/common/include/rte_eal.h)? Some of the includes in these headers are currently N/A to my toolchain (via CROSS=) or to my executive environment. Normally, these types of differences are just empty variables or something that allows the system build even when you do not support it. For example I do not have <sched.h> or <sys/queue.h> which are currently included in some EAL API headers. Maybe you should make simple empty headers, to work around those headers. I am sure it would be easier, but maybe someone has a better idea. Should more work into making the "common" part truly generic be put into this? We always like to see patches to make the EAL simpler to maintain, so please introduce a patch. Is the current EAL API frozen for compatibility reasons? Any "next" branch where such modifications are accepted? Changing a EAL API is really discouraged as it effect a lot of places. But we do have a method to change exposed APIs. It will take two releases to get your change into DPDK the first release gives notice and the second one allows the API to exist in the code. You can read more abort the process here: http://dpdk.org/dev make sure you read it all :-) Or, is there a straight method of enforcing my "xyzapp" symlinked EAL headers in the build directory without modifying the "common" Makefile? You should avoid symlinks in the main repo directories as they are difficult to maintain and some systems do not support them. Thank you, Alex Let us know if you need anything else. Regards, Keith
