Kconfig: The difference between 'def_bool y' and 'default y'

54 阅读 0 评论 36 点赞

我是靠谱客的博主幸福灯泡，最近开发中收集的这篇文章主要介绍Kconfig: The difference between 'def_bool y' and 'default y'，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

(07:53) - You are now in #zephyrproject
(07:53) - Topic: Zephyr Project opensource RTOS for IoT |  https://www.zephyrproject.org/developers/
(07:53) - Topic was set by anaZ!~nashif@ec2-52-44-31-151.compute-1.amazonaws.com in 14.02.2018 at 01:04:40
(08:29) - glima quit (Ping timeout: 252 seconds)
(08:55) - inakypg quit (Remote host closed the connection)
(08:57) <qianfan>Hi, How to make a distinction between 'default y' and 'def_bool y' in Kconfig system?
(08:57) <Ulfalizer>qianfan: 'def_bool y' is just a shorthand for 'bool' + 'default y'
(08:58) <Ulfalizer>config FOO
(08:58) <Ulfalizer>    bool
(08:58) <Ulfalizer>    default y
(08:58) <Ulfalizer>is the same as
(08:58) <Ulfalizer>config FOO
(08:58) <Ulfalizer>    def_bool y
(08:59) <Ulfalizer>can be handy if you have some more complicated expression, like this one:
(08:59) <qianfan>Thanks, and I find there has a menuconfig in drivers/gpio/gpio_sam: 'menuconfig GPIO_SAM, bool "Atmel SAM GPIO (PORT) driver', should I use 'def_bool y' ?
(09:00) <Ulfalizer>config HAS_SCREEN
(09:00) <Ulfalizer>    def_bool SCREEN_1 || SCREEN_2 || SCREEN_3
(09:00) <Ulfalizer>kinda dumb examples, but should get the point :D
(09:01) <Ulfalizer>qianfan: could just do a 'default y' there, since the type has already been given
(09:02) <qianfan>Seems it isn't a error if I use 'def_bool y' here, is it right?
(09:03) <Ulfalizer>nah, not an error. it's giving the same type twice, so it's a bit redundant, but it's not problematic at least.
(09:03) <Ulfalizer>you'd get a warning if you gave it a different type
(09:03) <Ulfalizer>like 'def_int 3'
(09:04) <Ulfalizer>this definition:
(09:04) <Ulfalizer>config foo
(09:04) <Ulfalizer>bool "foo"
(09:04) <Ulfalizer>def_bool y
(09:04) <Ulfalizer>is a shorthand for this:
(09:05) <Ulfalizer>config foo
(09:05) <Ulfalizer>bool "foo"
(09:05) <Ulfalizer>def_bool y
(09:05) <Ulfalizer>urr... a shorthand for this:
(09:05) <Ulfalizer>config FOO
(09:05) <Ulfalizer>bool
(09:05) <Ulfalizer>prompt "foo"
(09:05) <Ulfalizer>bool
(09:05) <Ulfalizer>default y
(09:06) <Ulfalizer>so not much pointing in using 'def_bool' there
(09:06) <Ulfalizer>*point
(09:06) <qianfan>And I found most of SoC's Kconfig.defconfig.series using 'def_bool y', is there has a recommendation which one is better?
(09:06) <Ulfalizer>'default y' might be better in Kconfig.defconfig file, for an obscure reason
(09:07) <Ulfalizer>if someone deletes the base definition of the symbol, then a 'default y' will mean that no type is given for the symbol
(09:07) <Ulfalizer>and then you'll get a warning that the symbol has no type. that makes it easier to discover redundant symbols in Kconfig.defconfig files.
(09:07) <Ulfalizer>other than that, either one is fine. it's just a small shorthand.
(09:08) <qianfan>Thanks you and I got it!
(09:08) <Ulfalizer>np
(09:09) <qianfan>How about write a issue that advise the developers using 'default y' instead 'def_bool y' in Kconfig.default?
(09:09) <Ulfalizer>might be nice to have a Kconfig best practices page at some point
(09:11) <Ulfalizer>qianfan: if you want to clean it up, i'll jump in and approve at least :)
(09:11) <Ulfalizer>should finish up some West-related stuff now though
(09:12) <qianfan>I think Kconfig best pratices page is very necessary, actually I don't know how to write a Kconfig file, I just copy-paste another Kconfig file and just modify
(09:13) <qianfan>So I want there has a practices page, at least tell me how to use 'default y'
(09:13) <Ulfalizer>yeah, kconfig-language.txt could be a bit clearer in spots too :/
(09:16) <Ulfalizer>qianfan: there is a more nitty-gritty explanation of how symbols get their value here btw: https://github.com/ulfalizer/Kconfiglib/blob/master/kconfiglib.py#L132
(09:17) <qianfan>Thanks you, I will learn it
(09:17) - Lncn quit (Disconnected by services)
(09:18) <Ulfalizer>basically, there are just three different ways for a symbol to get a value: a 'default', the user setting the symbol to a value, and a 'select'
(09:19) <Ulfalizer>if the symbol has a prompt (like in 'bool "foo"'), then the user can give it a value
(09:19) <Ulfalizer>if the symbol has no prompt or the user doesn't give it a value, then 'default' kicks in instead
(09:19) <Ulfalizer>and 'select' just overrides everything. it can be risky. :)
(09:20) - GAnthony_ quit ()
(09:21) <Ulfalizer>you can put conditions individually on defaults and prompts ('prompt "foo" if BAR' or 'default y if BAR'). usually, people use 'depends on' though. that puts the same condition on everything (disables all the prompts and defaults).
(09:21) <Ulfalizer>if no defaults kick in (e.g. because they have been disabled like that), then the symbol gets the value 'n' (if it's a bool)
(09:22) <qianfan>seems 'select' can only enable 'bool' type, is it right?
(09:22) <Ulfalizer>yup
(09:23) <Ulfalizer>'select' can easily lead to "spaghetti kconfig", so should be careful with it
(09:23) <qianfan>And what's the differences between menuconfig and config? seems both of them can set a 'bool' type
(09:23) <Ulfalizer>you mean .config files?
(09:24) <Ulfalizer>menuconfig is just a configuration interface
(09:24) <qianfan>No, I means something like this: 'menuconfig GPIO_SAM
(09:24) <Ulfalizer>ahh
(09:24) <Ulfalizer>it's just a presentation thing. if you use 'menuconfig', then you will get a separate menu in the menuconfig.py interface, instead of stuff being indented.
(09:25) <Ulfalizer>doesn't affect symbol evaluation at all. just a style hint.
(09:25) <Ulfalizer>all the symbols after the 'menuconfig' symbol that depend on it end up in the menu
(09:25) <Ulfalizer>as long as they follow immediately after it
(09:26) <qianfan>eg:
(09:26) <qianfan>menuconfig USART_SAM
(09:26) <qianfan>    bool "Atmel SAM USART driver"
(09:26) <qianfan>    ...
(09:26) <qianfan>config USART_SAM_PORT_0
(09:26) <qianfan>    bool "ENABLE USART0"
(09:26) <Ulfalizer>if you use 'config' instead, then they get indented instead
(09:26) - Sachiel quit (Ping timeout: 252 seconds)
(09:26) <qianfan>USART_SAM is menuconfig and USART_SAM_PORT_0 is config, both has bool type
(09:27) <Ulfalizer>qianfan: note that the symbols after it have 'depends on USART_SAM'
(09:27) <Ulfalizer>try jumping to USART_SAM in the menuconfig interface and see how it looks
(09:27) <Ulfalizer>and then try changing it to a 'config' instead and see how it looks
(09:27) <Ulfalizer>should clarify it :)
(09:28) <qianfan>USART_SAM contain USART_SAM_PORT_0 ~ USART_SAM_PORT_2
(09:28) <Ulfalizer>yup, in a separate "menu"
(09:28) <Ulfalizer>try changing it to 'config USART_SAM'
(09:28) <qianfan>seems 'menuconfig' is a specify 'config', it also can 'select' or set default value by using 'default y'
(09:29) <Ulfalizer>yep, both 'config' and 'menuconfig' define symbols
(09:30) <Ulfalizer>'menuconfig' is 'config' + a hint to display it as a menu in the menuconfig.py interface
(09:30) <Ulfalizer>just a style hint. doesn't affect anything else.
(09:31) <qianfan>Understand
(09:31) <Ulfalizer>it's a bit weird, but it's worked like that for ages, and it works alright :)
(09:32) <qianfan> Thanks you for teaching me the Kconfig
(09:33) <Ulfalizer>no probs