From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] eal: move compat includes to common meson file Date: Thu, 10 Jan 2019 11:33:46 +0100 Message-ID: <4446667.MZrz951Mch@xps> References: <98ec658513d481f8d22c8b438cc3fedc4a718d3f.1547054251.git.anatoly.burakov@intel.com> <2632071.H5f8aPozaM@xps> <20190110100220.GA13196@bricha3-MOBL.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Burakov, Anatoly" , David Marchand , dev@dpdk.org To: Bruce Richardson Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 5AF3B1B5DE for ; Thu, 10 Jan 2019 11:33:49 +0100 (CET) In-Reply-To: <20190110100220.GA13196@bricha3-MOBL.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 10/01/2019 11:02, Bruce Richardson: > On Thu, Jan 10, 2019 at 09:52:43AM +0100, Thomas Monjalon wrote: > > 10/01/2019 09:45, Burakov, Anatoly: > > > On 09-Jan-19 9:36 PM, Thomas Monjalon wrote: > > > > 09/01/2019 21:51, Bruce Richardson: > > > >> One other point I'd make is that having compat as a separate library seems > > > >> a little like overkill to me - it's just one header file! Is there a reason > > > >> why we don't just move it into the EAL where everyone can use it without > > > >> having to specify another dependency? > > > > > > > > +1 for moving compat into EAL. > > > > > > Presumably the reason to keep it separate would be to enable depending > > > on it for libraries that EAL itself depends on (i.e. kvargs). > > > > Yes, forgot this one. > > I also forgot that. However, that does bring up the thought that for some > of our headers we may want them available for all libraries even before EAL > is compiled up. [I think this hits on the idea Thomas was discussing of > splitting EAL up into two, where we have a core part that is always > compiled first and has no dependencies followed by another which is built > later and can have dependencies.] > > For this specific issue, my thought is that we should indeed move compat.h > into EAL, but also add the EAL common/include/ path to the global include > path for the project, so all EAL headers (e.g. including those with defines > for cacheline size, and other common macros) are just always available. > Libs like kvargs and others should be able to use RTE_DIM etc. for > consistency with the rest of DPDK. You are describing a cheap split :) It would bring some definitions but not some non-inline functions. I still think we should split in 2 libraries: - EAL as "Environment Abstraction Layer", i.e. basic stuffs - Initialization + core features (bus/dev and mem) We could even move bus/dev and mem in separate libraries.