include/device: Add device_enum.h #58112
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bjarki-andreasen
force-pushed
the
kernel_device_enumeration_feature
branch
11 times, most recently
from
1544b2d to
76157ad
Compare
added 6 commits
May 22, 2023 23:43
This header contains the macros which will become available using generated code in the upcomming commits. An additional step has also been added to the CMakeLists.txt to create an empty file to be included until the actual file is generated by the build system. The macros will allow the application to get access to all struct devices and their properties, based on their class rather than devicetree node. The devicetree node will still be available if it was before, and the macros even provide a direct link to the node the device belongs to. It also provides the reverse link from devicetree node to struct device enumeration. Signed-off-by: Bjarki Arge Andreasen <[email protected]>
The device enumeration feature requires all devices to place their API implementation in linker sections by api type. This commit adds a macro to place the <api>_driver_api structs in the correct section in ROM, and adds a script which uses the tag __subsystem to identify all existing driver API types and generate iterable sections for them. The script is invoked from the top CMakeLists.txt Signed-off-by: Bjarki Arge Andreasen <[email protected]>
This commit updates the cmake function toolchain_ld_link_elf() to take a new argument: LIBRARIES, which is the list of libraries to link to target. Previously this was implicitely set to ZEPHYR_LIBS_PROPERTY, as this was used for all linker steps. This is no longer the case when the kernel, containing all struct devices, has to be built and linked before including the application. The application (app library) is contained in the ZEPHYR_LIBS_PROPERTY list, and so a new list must be created which excludes this library (and any other libraries which must be able to use the output from the new first linker step, like subsystems for example). Signed-off-by: Bjarki Arge Andreasen <[email protected]>
This commit splits the zephyr libraries into two categories, kernel and kernel + app. kernel libraries are all libraries except the application. It then uses the kernel libraries only when building the kernel, finally adding the app library at the last stage, which will now always be built, regardless of if any files where generated. Signed-off-by: Bjarki Arge Andreasen <[email protected]>
This commit adds the api member of a struct device to the Device class in the elf_parser. Along with this, the new function find_section_by_address() has been added to the ZephyrELF class to be used for downstream scripts to get the section an address is within, like the api of a struct device. Signed-off-by: Bjarki Arge Andreasen <[email protected]>
This commit adds the script which generates device enumerations from the zephyr_pre0 elf file, to be included by the application. Signed-off-by: Bjarki Arge Andreasen <[email protected]>
bjarki-andreasen
force-pushed
the
kernel_device_enumeration_feature
branch
from
76157ad to
bf273db
Compare
|
Architecture WG:
|
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
This was referenced Apr 22, 2024
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Device enumeration by class for subsystem
Introduction
This PR splits the libraries built by the build system into kernel libraries, and application libraries, to allow for parsing the pre built kernel for struct devices, to identify existing devices and their class, which are then presented to the application through C macros.
To get an overview of what will be possible, look to the first commit, device_enum.h The macros in this file will be available to all non kernel libraries.
The details
We currently have a multi stage build system, which uses intermediary elf files to generate source code for device handles and user space. This PR expands the capabilities of the build system, by splitting it into two layers, the kernel layer, and the application layer. This allows us to build the entire kernel, from which we can then find information like existing struct devices, which we can then generate macros for, to be made available as a static library to the application which is built after the kernel has been built.
Future work
The application layer can be extended to include some subsystems like shells, filesystems, networking etc. which are not part of the kernel or drivers, they use it like the application. These subsystems can also make use of the generated content from the kernel build. We could create some tag, which could be attached to zephyr libraries to indicate if they are part of the kernel or not to make this scalable.
To discuss