On 3/1/2019 5:05 PM, Ferruh Yigit wrote: > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin Jacob) wrote: >> -----Original Message----- >>> Date: Wed, 11 Oct 2017 15:02:51 +0200 >>> From: Thomas Monjalon <thomas at monjalon.net> >>> To: Jerin Jacob <jerin.jacob at caviumnetworks.com> >>> Cc: dev at dpdk.org, bruce.richardson at intel.com >>> Subject: Re: [dpdk-dev] [PATCH] eal: change init macro as exec environment >>> specific >>> >>> 07/08/2017 14:04, Jerin Jacob: >>>> baremetal execution environments may have a different >>>> method to enable RTE_INIT instead of using compiler >>>> constructor scheme. Move RTE_INIT* definition under >>>> exec-env to support different execution environments. >>>> >>>> Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com> >>>> --- >>>> app/test-eventdev/evt_test.h | 2 +- >>>> lib/librte_eal/bsdapp/eal/Makefile | 2 +- >>>> .../bsdapp/eal/include/exec-env/rte_eal.h | 51 >>>> ++++++++++++++++++++++ >>>> lib/librte_eal/common/eal_common_log.c | 2 + >>>> lib/librte_eal/common/include/rte_bus.h | 2 + >>>> lib/librte_eal/common/include/rte_eal.h | 6 --- >>>> lib/librte_eal/common/include/rte_tailq.h | 2 + >>>> lib/librte_eal/linuxapp/eal/Makefile | 2 +- >>>> .../linuxapp/eal/include/exec-env/rte_eal.h | 51 >>>> ++++++++++++++++++++++ >>>> 9 files changed, 111 insertions(+), 9 deletions(-) >>>> create mode 100644 lib/librte_eal/bsdapp/eal/include/exec-env/rte_eal.h >>>> create mode 100644 lib/librte_eal/linuxapp/eal/include/exec-env/rte_eal.h >>> >>> I am not a big fan of duplicating code for Linux and BSD. >>> >>> Maybe we should have different splits and include a common file >>> in Linux and BSD? >> >> OK. This is doable. >> >>> >>> I feel it would be easier to think about the split when adding >>> a new environment. >>> It is also an open question whether we want to support (again) some >>> bare metal environments. >> >> IMO, A factor could be, how much we are OK to change? >> >> Our internal prototype implementation for a bare metal environment >> shows things are already in place and may need minor changes like this to >> accommodate a bare metal execution environment(accounting the latest >> changes of moving pci to driver/pci/..) >> >> If no one care about need for such abstraction then we could drop this >> patch. We can always keep local copy of such patches in our internal >> tree. I thought to upstream it as it may be useful for someone else and >> it is easy for us maintain if changes are in >> lib/librte_eal/<new environment>/eal/ and drivers/*/ > Hi Jerin, Thomas, > > This is an old patch, the abstraction seems good idea but it comes with a > duplication. > > Is there an intention to continue the work? Are we waiting for any decision? > Any objection to mark it as rejected?
For reference, mentioned patch: https://patches.dpdk.org/patch/27474/ > > Thanks, > ferruh >
