[dpdk-dev] Question about adding a new EAL

[Wiles, Keith]

On May 22, 2018, at 2:23 PM, Alexandru Ciobotaru <alex.ciobotaru at gmail.com<mailto:alex.ciobotaru at 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