[dpdk-dev] [PATCH] eal: change init macro as exec environment specific
thomas at monjalon.net
Fri Mar 1 18:28:38 CET 2019
01/03/2019 18:05, Ferruh Yigit:
> On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com (Jerin Jacob) wrote:
> > From: Thomas Monjalon <thomas at monjalon.net>
> >> 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
> Is there an intention to continue the work? Are we waiting for any decision?
> Any objection to mark it as rejected?
I am not sure there is a real desire to make DPDK
ready for bare-metal (back again).
If any of you are aware of a real use-case, we can re-consider.
More information about the dev