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 > duplication. > > 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.
