From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: Question about adding a new EAL Date: Tue, 22 May 2018 19:59:32 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Alexandru Ciobotaru Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 8291B2C4F for ; Tue, 22 May 2018 21:59:35 +0200 (CEST) In-Reply-To: Content-Language: en-US Content-ID: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Must use text only :-( darn mail program > On May 22, 2018, at 2:23 PM, Alexandru Ciobotaru wrote: >=20 > Greetings, I can not answer all of your questions, but maybe a few. >=20 > I'm currently checking on how to add new EAL "app" to the DPDK so I start= ed > 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: >=20 > 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 heade= rs > are currently N/A to my toolchain (via CROSS=3D) 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 or 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 pleas= e introduce a patch. > Is the current EAL API frozen for compatibility reasons? Any "next" branc= h > 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 ge= t your change into DPDK the first release gives notice and the second one a= llows the API to exist in the code. You can read more abort the process her= e: 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 difficul= t to maintain and some systems do not support them. You may want to do an RFC email subject to discuss your ideas on changing E= AL code first to eliminate extra work. >=20 > Thank you, > Alex Regards, Keith