Network stack runtime configuration #97266
Draft
+5,012
−389
Conversation
This file contains hidden or 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
Add a way to convert a user supplied yaml file to a configuration file. For networking, a C header file is generated which can then be included to the application. Add a cmake function that calls the generate config macros with suitable values for networking needs. Signed-off-by: Jukka Rissanen <[email protected]>
jukkar
added
the
In progress
pdgendt
reviewed
Oct 9, 2025
There was a problem hiding this comment.
Thanks for the info, I will look into converting the code.
|
This contains rules to validate network configuration in yaml format. Signed-off-by: Jukka Rissanen <[email protected]>
Add a python script that converts a user supplied network configuration yaml file to a valid network configuration C header file. Signed-off-by: Jukka Rissanen <[email protected]>
If CONFIG_NET_CONFIG_SETTINGS is enabled, then the network configuration library will check if a yaml file net-init-config.yaml is found in the application directory and use it to generate network initial configuration that is then applied when the device boots. If the yaml file is not there, then the relevant Kconfig options are used to create initial network configuration. Signed-off-by: Jukka Rissanen <[email protected]>
User can set NET_INIT_CONFIG_FILE to override the name of the default configuration file name which is net-init-config.yaml This way a substitute yaml config file can be used instead of the default one. Signed-off-by: Jukka Rissanen <[email protected]>
Example networking yaml configuration file. This contains more complex network setup that can be used to see what can be done. Signed-off-by: Jukka Rissanen <[email protected]>
Add documentation about the network stack initialization using a yaml file. Signed-off-by: Jukka Rissanen <[email protected]>
If user is not interested in the mask length, the value can be set to NULL so that it is not been returned to the caller. Signed-off-by: Jukka Rissanen <[email protected]>
If user has supplied a yaml file, it is used as configuration data that is applied to network configuration. In this case the CONFIG_NET_CONFIG_* Kconfig variables used for configuration are ignored. Signed-off-by: Jukka Rissanen <[email protected]>
Add simple unit tests that verify that options specified in yaml file can be used to configure network stack. Signed-off-by: Jukka Rissanen <[email protected]>
The hash value is used to detect if the yaml format file has changed so that we know that the data format is changed and the previous configuration in settings should be abandoned. Signed-off-by: Jukka Rissanen <[email protected]>
Add __xxx_changed boolean flag to the strcut definition so that we know if the value was changed by the user. Signed-off-by: Jukka Rissanen <[email protected]>
Add set and get functions that return/set either the default settings or if user has changed them, the user adjusted value. Make these two functions to use settings API. Signed-off-by: Jukka Rissanen <[email protected]>
Add "net config" command to view the current configuration and modify or remove the configuration data. Signed-off-by: Jukka Rissanen <[email protected]>
Convert network configuration schema in pykwalify format to jsonschema format because pykwalify is being deprecated in zephyr and jsonschema is used in the future. Signed-off-by: Jukka Rissanen <[email protected]>
As pykwalify is no longer used in zephyr, the yaml schema format is changed to jsonschema format. This requires changes to python script that generates C struct configuration definitions. Signed-off-by: Jukka Rissanen <[email protected]>
jukkar
force-pushed
the
devel/net-config-overhaul
branch
from
435dd17 to
871eae7
Compare
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Note that this PR is continuing the work started on #68127. Most of the commits come directly from that PR, couple of latest ones are new as they add settings db support.
Executive summary of how the PR works:
More detailed description follows:
This PR adds support to autoconfigure the network sub-system when the device boots. It is mainly meant to be used when there are multiple network interfaces in the system. In that case Kconfig based network configure parameters cannot be used easily as the system will only apply the configuration to one of the network interfaces.
This is related to old enhancement #29750 request. There it was pondered to use devicetree to configuring network stack. As DT is only meant to describe hardware configuration some other way of configuration is needed.
This PR uses yaml file to describe network stack configuration. The configuration data in yaml file is not restricted to network configuration but any subsystem configuration could be done via it. I concentrated to network configuration as we need this multi network interface autoconfiguration in networking.
The PR provides minimal infrastructure to validate a user supplied yaml file and then generate a C configuration data file from it. So we do not import the yaml file directly to the zephyr image, but we use a generator script to generate C header file that is then included by the network config library. When the device boots, the network configurator reads the configuration stored in ROM, and applies the configuration to each network interface found in the system. When the user creates the yaml file, she/he should know the network configuration in order to map the yaml file to the device in use. The configuration from ROM is used as a default read-only configuration.
The user supplied yaml file can be stored outside of zephyr. When building the network application, the location of the yaml file is given so the build system can then utilize it.
At runtime, user is able to adjust the configuration values stored in ROM. The changes will be stored in settings database, currently using NVS backend. The changes to the network configuration can be done via
net_config_get/set()API or via anet configshell which provides commands (view/set/remove) to adjust the values in the network configuration. When the device boots, the default configuration in ROM is used as a base and user updated configuration values from settings db are applied on top of that.This PR is still work in progress, more testing is needed and documentation needs more work if this is to be merged.