[dpdk-dev] [PATCH] eal: change init macro as exec environment specific

Wiles, Keith keith.wiles at intel.com
Tue Apr 2 15:20:05 CEST 2019



> On Apr 2, 2019, at 7:57 AM, Thomas Monjalon <thomas at monjalon.net> wrote:
> 
> 11/10/2017 16:33, Jerin Jacob:
>> 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 ++++++++++++++++++++++
> 
> I sent a patch to flatten the hierarchy, removing exec-env.
> And I'm not sure about the file name rte_eal.h.
> Please could you move it to lib/librte_eal/<os>/eal/include/rte_exec_env.h
> or another better name? Note that Windows is introducing rte_os.h.
> PS: I'm not sure about the intent of rte_os.h. Should it be rte_libc.h?

I agree here unless the rte_os.h or (rte_libc.h) is really a header to just include rte_windows_libc.h, rte_linux_libc.h or rte_<OS>_libc.h to simplify including OS specific headers and differences in libc designs.
> 
>>>> 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 ++++++++++++++++++++++
>>> 
>>> 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.
> 
> After some thoughts about Windows port, I think we need to consider
> a better split.
> The constructors are the same for Linux, BSD and Windows, isn't it?
> Is it related to splitting between POSIX libc and others?
> 
> 
> 

Regards,
Keith



More information about the dev mailing list