Re: [PATCH] eal: change init macro as exec environment specific

[Ferruh Yigit <ferruh.yigit@intel.com>]

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
>