Support maintaining subsystems out-of-tree

[SebastianBoe]

Use-case

Users want to maintain Zephyr components out-of-tree like boards, arch's, drivers etc.

This github issue tracks the use-case of maintaining a driver out-of-tree.

Root cause

A driver would require devconfig to be populated and for the system call infrastructure to find the system call. The devconfig mechanism has been observed to work, but syscall detection does not.

Workaround today

When an application needs a custom driver that is not supported by Zephyr it would
have to maintain it in a fork of Zephyr that contained the driver.

Solution

Unless additional testing finds more issues, an API for adding custom syscall header directories might be the simplest solution.

[SebastianBoe]

Strange, was not able to reproduce the issue.

sample: zephyr/samples/hello_world
Board: nrf52_pca10040
patch: SebastianBoe@26e947d

After building I was able to observe that devconfig was populated with an entry for the 'app' driver.

devconfig 0x000000000000a3a0 0x84
0x000000000000a3a0 __devconfig_start = .
(.devconfig.)
.devconfig.init
0x000000000000a3a0 0xc libapp.a(entropy_nrf5.c.obj)
.devconfig.init
0x000000000000a3ac 0xc zephyr/libzephyr.a(soc.c.obj)
.devconfig.init

Didn't actually test that the driver was functional, but the original report was that there was no entry in devconfig ...

[pboettch]

I'm back on this link-problem and have found another case which creates a problem: libraries added at application-level which are using functions and features from zephyr which are not used by zephyr itself.

include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(NONE)

# bad example as code.c could be added to app - imagine an imported library or a library from a sub-directories which is there because of code-structure
add_library(lib code.c) # uses pipes for example 

target_sources(app
    PRIVATE
        main.c)
target_link_libraries(app lib)

If now the zephyr-part (the part which is linked within --start-group and --end-group) is not using pipes the linker throws away, for example, _impl_k_pipe_put. As lib is using it we get:

build/zephyr/include/generated/syscalls/kernel.h:105: undefined reference to `_impl_k_pipe_put'
build/zephyr/include/generated/syscalls/kernel.h:105: undefined reference to `_impl_k_pipe_put'
lib/liblib.a(code.c): In function `k_pipe_init':
build/zephyr/include/generated/syscalls/kernel.h:103: undefined reference to `_impl_k_pipe_init'

One solution is add something which add target_link_libraries(app ..) to the link-group via generator-expressions. I was unable to come up with a working solutions using CMake-targets. What works are filenames: I created a custom property to which I added filenames at the same time when calling target_link_libraries() in app's CMakeLists.txt. However, knowing the filename is not always easy/possible (generator expressions seem not to be evaluated recursively).

Then I found several discussions talking about how to handle circular dependencies of libraries (not really ours case but the problem is similar). CMake has that LINK_INTERFACE_MULTIPLICITY variable which adds the dependent static libraries multiple times to the linker-line. This looks promising to me, but I don't if there is a special reason for this project to use --start-group and --end-group.

What would you say?

[carlescufi]

@SebastianBoe this came up during the Release Readiness meeting today. Can you give us some feedback on whether we need to do more work on this?

[SebastianBoe]

Hi,

will get this cleared up by the end of the week.

[pboettch]

I'm available as well for discussions (elsewhere than here or by mail if needed). I'd love to have a nice solution.

[SebastianBoe]

I can confirm that out-of-tree drivers are not supported yet because drivers use system calls and the system call infrastructure is currently assuming that all system call declarations are located in
zephyr/include.

Offending line:
https://github.com/zephyrproject-rtos/zephyr/blob/master/CMakeLists.txt#L343

[SebastianBoe]

@pboettch : I will create a new issue for this observation/bugreport:
#5554 (comment)