NUM_KERNEL_OBJECT_FILES is too small

[andrewboie]

I found this when trying to build frdm_k64f/tests/drivers/build_all/test_build_sensors_a_m

In file included from /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/include/arch/arm/cortex_m/scripts/linker.ld:21:0,
                 from /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/arch/arm/soc/nxp_kinetis/k6x/linker.ld:31:
/home/buildslave/src/github.com/zephyrproject-rtos/zephyr/include/linker/linker-defs.h:115:2: error: #error "Max supported kernel objects is 32."
 #error "Max supported kernel objects is 32."
  ^~~~~

32 is unreasonably small limit of the number of .o files for a real-world application.

[andrewboie]

Apparently this is a limitation of UTIL_LISTIFY and we really need to just get rid of this.

#ifndef NUM_KERNEL_OBJECT_FILES
#error "Expected NUM_KERNEL_OBJECT_FILES to be defined"
#elif NUM_KERNEL_OBJECT_FILES > 32
#error "Max supported kernel objects is 32."
/* TODO: Using the preprocessor to do this was a mistake. Rewrite to
   scale better. e.g. by aggregating the kernel objects into two
   archives like KBuild did.*/
#endif

[lpereira]

I would even rename UTIL_LISTIFY to _UTIL_LISTIFY to discourage it being used by people and make it easier to get rid of it in the next version.

[SebastianBoe]

I would even rename UTIL_LISTIFY to _UTIL_LISTIFY to discourage it being used by people and make it easier to get rid of it in the next version.

I wouldn't go that far ...

It is useful to generate sequences of code that are relatively short.

e.g. it is the cleanest possible solution (that I know of) to solve problems like the below.

#define TIMER_IRQHANDLER_GENERATOR(j, _)                                                            \
    void TIMER##j##_IRQHandler(void)                                                                \
    {                                                                                              \
        timer_i_irqhandler(j);                                                                      \
    }

#ifdef TIMER_COUNT
STD_SHARED_LIB_LISTIFY(TIMER_COUNT, TIMER_IRQHANDLER_GENERATOR)
#endif

It was just inappropriately used here.

[andrewboie]

IMO UTIL_LISTIFY needs to die and we should just generate the code with a post-build step. It just doesn't scale. I am not sure if #7632 (the successor to CONFIG_APPLICATION_MEMORY) needs it.

[tejlmand]

RFC #8541 and issue #8441 indirectly address this issue.

By significantly reducing the numbers of CMake libraries, as example bluetooth goes from up to 6 sub-libraries to just a single. Net can go from up to 12 sub-libraries to also a single.

A samples app, such as bluetooth/ipsp, will go from 15 libraries that would be in Kernel spaces and down to just 6.
Of course the actual reduction depends on how much is enabled in the app, but for subsystems such as net, the potential gain is high.

In the ipsp case the following reduction is seen:
libzephyr.a (stays)
libkernel.a (stays)

libdrivers__gpio.a
libdrivers__serial.a
libdrivers__entropy.a
=> libdrivers.a

libarch__arm__core.a
libarch__arm__core__cortex_m.a
libarch__arm__core__cortex_m__mpu.a
=> libarch_arm.a

libsubsys__bluetooth__common.a
libsubsys__bluetooth__host.a
libsubsys__bluetooth__controller.a
=> libsubsys_bluetooth.a

libsubsys__net.a
libsubsys__net__l2.a
libsubsys__net__ip.a
libsubsys__net__lib__config.a
=> libsubsys_net.a