Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kconfig: add support for warnings when using experimental features #33566

Merged
merged 4 commits into from
Oct 22, 2021

Conversation

tejlmand
Copy link
Collaborator

This PR allows a user to have a warning printed if any experimental features are used in Zephyr.

As example, building samples/hello_world with THREAD_MONITOR which is experimental will look as:

$ cmake -GNinja -DBOARD=nrf52840dk_nrf52840 -Bbuild samples/hello_world/ -DCONFIG_THREAD_MONITOR=y
Parsing /projects/github/ncs/zephyr/Kconfig
Loaded configuration '/projects/github/ncs/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'
Merged configuration '/projects/github/ncs/zephyr/samples/hello_world/prj.conf'
Merged configuration '/projects/github/ncs/zephyr/build/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '/projects/github/ncs/zephyr/build/zephyr/.config'
Kconfig header saved to '/projects/github/ncs/zephyr/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 7.3.1
....

Enabling this new warning together with THREAD_MONITOR, will give:

$ cmake -GNinja -DBOARD=nrf52840dk_nrf52840 -Bbuild samples/hello_world/ -DCONFIG_WARN_EXPERIMENTAL=y -DCONFIG_THREAD_MONITOR=y
Parsing /projects/github/ncs/zephyr/Kconfig
Loaded configuration '/projects/github/ncs/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'
Merged configuration '/projects/github/ncs/zephyr/samples/hello_world/prj.conf'
Merged configuration '/projects/github/ncs/zephyr/build/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '/projects/github/ncs/zephyr/build/zephyr/.config'
Kconfig header saved to '/projects/github/ncs/zephyr/build/zephyr/include/generated/autoconf.h'

warning: Experimental symbol THREAD_MONITOR is enabled.

.....

This adds a new setting which allows a user to print a warning when
a feature that is marked [EXPERIMENTAL] is enabled.

Signed-off-by: Torsten Rasmussen [email protected]

galak
galak previously requested changes Mar 22, 2021
Copy link
Collaborator

@galak galak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea, but I don't think we should be modifying scripts/kconfig/kconfig.py to do this. Maybe a separate script similar to scripts/kconfig/hardenconfig.py?

@tejlmand
Copy link
Collaborator Author

I like the idea, but I don't think we should be modifying scripts/kconfig/kconfig.py to do this. Maybe a separate script similar to scripts/kconfig/hardenconfig.py?

Except that hardenconfig.py is a build target that users can call with ninja hardenconfig, similar to menuconfig and other extra targets, and thus only take resources when it's called.

The CONFIG_WARN_EXPERIMENTAL=y allows you to get a warning if experimental features are enabled as part of the CMake invocation, similar to other build warnings.

The motivation for updating kconfig.py is because it has the parsed kconfig tree available, and thus no overhead of re-invoking Kconfig parsing at CMake time.

@tejlmand
Copy link
Collaborator Author

@galak also notice, kconfig.py already does various checking of the Kconfig tree today:

check_no_promptless_assign(kconf)

check_assigned_sym_values(kconf)

check_assigned_choice_values(kconf)

@rugeGerritsen
Copy link
Collaborator

In a very limited set of places we have constructs like:

config BT_CTLR_ADV_EXT
	bool "LE Advertising Extensions" if !BT_LL_SW_SPLIT

config BT_CTLR_ADV_EXT
	bool "LE Advertising Extensions [EXPERIMENTAL]" if BT_LL_SW_SPLIT

I would assume that we need to rewrite those to something similar to

config BT_CTLR_ADV_EXT
	bool "LE Advertising Extensions"

config BT_CTLR_ADV_EXT_SW_LL_SPLIT
	bool "LE Advertising Extensions [EXPERIMENTAL]"
	default y if BT_LL_SW_SPLIT && BT_CTLR_ADV_EXT

Otherwise warning: Experimental symbol BT_CTLR_ADV_EXT will be printed even if BT_LL_SW_SPLIT is not selected. See https:/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/controller/Kconfig#L460

Would it be possible to make a similar construct that fails the configuration, as opposed to printing a warning, if an experimental feature is selected?

@carlescufi
Copy link
Member

I like the idea, but I don't think we should be modifying scripts/kconfig/kconfig.py to do this. Maybe a separate script similar to scripts/kconfig/hardenconfig.py?

We discussed this, but I actually think this might well belong in this file. It is, after all, our bridge to Kconfig, and this is pretty much an extension to Kconfig that we are adding.

@tejlmand
Copy link
Collaborator Author

I would assume that we need to rewrite those to something similar to

Let me take a second look.
Right now a warning is printed if symbol is enabled, but I did consider to only print the warning for enabled symbols if they were also visible.
I assume that would help in this particular case.

The disadvantage is of course that a symbol marked [EXPERIMENTAL] will not be printed if it is not visible, but I don't know if we have any such cases where an experimental symbol can be enable but not shown, where we would like the warning.

Main point: we need to consider best user experience on this.

Would it be possible to make a similar construct that fails the configuration, as opposed to printing a warning, if an experimental feature is selected?

It would, but then you should take this issue into consideration #9573
meaning that failing the configuration currently prevents the user from entering menuconfig to fix the reason.

@tejlmand
Copy link
Collaborator Author

@rugeGerritsen you probably need to take a look at that Kconfig snippet anyway, cause if BT_LL_SW_SPLIT=n you'll see this is menuconfig today, which I assume is not your intention:
image

@nashif
Copy link
Member

nashif commented Mar 22, 2021

we could revert back to the original experimental support in Kconfig where each experimental Kconfig would select EXPERIMENTAL and then just print something out if any experimental features are enabled....

@tejlmand
Copy link
Collaborator Author

we could revert back to the original experimental support in Kconfig where each experimental Kconfig would select EXPERIMENTAL and then just print something out if any experimental features are enabled....

if we did have something like this back in time, then it might be worth knowing why it was removed.
Did users forget to make a select EXPERIMENTAL or was it insufficient to just print experimental in use, and not know which feature that was the root cause ?

With this PR, users would be informed about the symbol

warning: Experimental symbol THREAD_MONITOR is enabled.

This adds two new Kconfig settings.

The first setting `EXPERIMENTAL` which is a promptless symbol.
This symbol must be selected by any setting which is used to enable
an experimental feature.

The second setting is `WARN_EXPERIMENTAL` which is a user controlled
setting that configures the build system to print a warning when
experimental features are enabled.

Signed-off-by: Torsten Rasmussen <[email protected]>
Copy link
Member

@nashif nashif left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. need to see some documentation about this and how this can be used. We do not want people depending on this kconfig and this is not documented anywhere, this can have negative results.
  2. I remember seeing a change that had all experimental features converted to use this, we need to have at least few places use this, consider it a test and a reference to be added in the docs.

@carlescufi
Copy link
Member

2. I remember seeing a change that had all experimental features converted to use this, we need to have at least few places use this, consider it a test and a reference to be added in the docs.

Do you mean this one @nashif ? #39473

With the introduction of `EXPERIMENTAL` and `WARN_EXPERIMENTAL` in
Zephyr all subsys/bluetooth and drivers/bluetooth/hci settings having
`[EXPERIMENTAL]` in their prompt has has been updated to include
`select EXPERIMENTAL` so that developers can enable warnings when
experimental features are enabled.

Signed-off-by: Torsten Rasmussen <[email protected]>
With the introduction of `EXPERIMENTAL` and `WARN_EXPERIMENTAL` in
Zephyr all subsys/canbus, subsys/net/l2/canbus, and drivers/can settings
having `[EXPERIMENTAL]` in their prompt has has been updated to include
`select EXPERIMENTAL` so that developers can enable warnings when
experimental features are enabled.

Signed-off-by: Torsten Rasmussen <[email protected]>
This commit adds description of the `WARN_EXPERIMENTAL` Kconfig setting
to the application development guide.

It describes the use of `CONFIG_WARN_EXPERIMENTAL` along with an
example of the warning output when experimental features are enabled.

Signed-off-by: Torsten Rasmussen <[email protected]>
@tejlmand
Copy link
Collaborator Author

1. need to see some documentation about this and how this can be used. We do not want people depending on this kconfig and this is not documented anywhere, this can have negative results.

Done, see commit: 05c22eb

2. I remember seeing a change that had all experimental features converted to use this, we need to have at least few places use this, consider it a test and a reference to be added in the docs.

Done, I have taken bluetooth and canbus that uses select EXPERIMENTAL from #39473 into this PR.
Still waiting for confirmation on the remaining settings marked EXPERIMENTAL that they are still considered at an experimental state.

@tejlmand tejlmand removed the request for review from ulfalizer October 22, 2021 09:02
@nashif
Copy link
Member

nashif commented Oct 22, 2021

Do you mean this one @nashif ? #39473

ah, yes. sorry :-)

@carlescufi carlescufi merged commit f17630b into zephyrproject-rtos:main Oct 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants