Re: [dpdk-dev] Question about adding a new EAL

["Wiles, Keith" <keith.wiles@intel.com>]

Must use text only :-( darn mail program


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

You may want to do an RFC email subject to discuss your ideas on changing EAL code first to eliminate extra work.

> 
> Thank you,
> Alex

Regards,
Keith