Kconfig.defconfig is undocumented and unclear #7159
Assignees
Labels
area: Documentation
Enhancement
Changes/Updates/Additions to existing features
priority: medium
Medium impact/importance bug
Comments
|
CC @carlescufi |
MaureenHelm
added
Enhancement
|
I don't know what the design behind Kconfig.defconfig is either. But one would think that the use-case for having board-specific immutable/fixed configs should be covered by DTS and then input to Kconfig like ARCH is. |
|
Agreed, these files are a mystery. I've assigned you to this @ulfalizer so you can document them. |
ulfalizer
added a commit
to ulfalizer/zephyr
that referenced
this issue
Apr 26, 2018
In particular, try to demystify Kconfig.defconfig files, and provide guidelines on whether configuration settings should go in BOARD_defconfig or Kconfig.defconfig. The board porting section seems to be the most relevant one here, so put the documentation there, with some "see also" links from elsewhere. Things could be reorganized later if needed. Give a general overview of visible and invisible Kconfig symbols as well, as that ties in with the configuration scheme. This is reverse-engineering on my part. The configuration scheme doesn't seem to be documented anywhere prior. Fixes: zephyrproject-rtos#7159 Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
carlescufi
pushed a commit
that referenced
this issue
Apr 27, 2018
In particular, try to demystify Kconfig.defconfig files, and provide guidelines on whether configuration settings should go in BOARD_defconfig or Kconfig.defconfig. The board porting section seems to be the most relevant one here, so put the documentation there, with some "see also" links from elsewhere. Things could be reorganized later if needed. Give a general overview of visible and invisible Kconfig symbols as well, as that ties in with the configuration scheme. This is reverse-engineering on my part. The configuration scheme doesn't seem to be documented anywhere prior. Fixes: #7159 Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Kconfig.defconfigfiles were mysterious to me, meaning they're probably super mysterious to people who are less used to Kconfig. They ought to be documented, both to make the design clearer, and to prevent people from putting stuff in random places.The prefer-later-defaults behavior (see #7054) could be documented at the same time.
Here's an overview of what I think the thinking behind those files is, taken from #6890 (comment):
Boards have some fixed setting/symbol X.
If a user picks a particular board, they shouldn't be able to change X in e.g.
menuconfig, so X has noprompt.Since X has no prompt, it can't be assigned its board-specific value via a
.config(*_defconfigin this case) file.X still needs to get its board-specific value somehow though, and that's what those
Kconfig.defconfigfiles are for. You could have a single symbol definition with all thedefaults too, but it would get spammy.The text was updated successfully, but these errors were encountered: