Implications of multiple config's in Kconfig.

What are the implications of doing this in one of the Kconfig files in one of my modules?

should this override the first configuration of NFCT_IRQ_PRIORITY?
from my undersanding it shouldnt but when I try to check this with an example I create on my own, I get it overrides it.

this is how I tested it:


if it doesnt override the dependencies, then I shouldnt be able to get y on all of them, but when I check the .config file I see:


is this a bug? 

Parents
  • The way I read your Kconfig file:

    TESTING_3 is created and assigned default value y

    TESTING0 is not created, because of testing1

    TESTING1 is created with default value y

    TESTING0 is created because TESTING_3 exists. Default value y

    So in the end I would expect TESTING 0 1 and 3 to be y.

    I don't recall whether the order of these have anything to say, but the if's and endif's decide whether they are created or not. 

    If you mean that it is wrong, can you explain how you expect it to work, and upload an application showing it?

    Best regards,

    Edvin

  • Hey Edvin, thank you for the reply.

    The way I would expect it to work is for every config to extend the already existing definition, becaue intuitively I wouldn't expect another config to make me lose dependencies.
    In this case, for example, I use config with the TESTING0 symbol twice, I would expect that if both config are taken into account, the final defination of TESTING0 to be 

    config TESTING0
           bool "testing0"
           depends on !TESTING1
           default y

    where the default turned to y because it was overrided by the second config statement on TESTING0, and I dont lose the dependency on !TESTING1

    In practice, as you can see in the images I uploaded, both TESTING0 and TESTING1 evaluate to y meaning I do lose the dependency on !TESTING1 due to the second config statement. 
    I wouldn't expect that.

    to see this in your application all you need to do is copy paste this:

    config TESTING_3

    bool "testing 3"

    default y

    config TESTING0

    bool "testing0"

    depends on !TESTING1

    default n

    config TESTING1

    bool "testing1"

    default y

    if TESTING_3

    config TESTING0

    default y

    endif

    to any Kconfig file that is evaluated, in any application, and then look at the .config and see the behavior.








  • shlomots said:
    to see this in your application all you need to do is copy paste this:

    I could do that, but the output from your test is what I expect to happen. 

    I still cannot grasp what you are trying to point out. 

    Perhaps you want to modify the default value based on your dependencies? If so, you can look at how e.g. the NCS\nrf\subsys\bluetooth\controller\Kconfig defines it's "config BT_CTLR_SDC_PERIPHERAL_COUNT:

    config BT_CTLR_SDC_PERIPHERAL_COUNT
    	int "Number of concurrent peripheral roles"
    	default BT_MAX_CONN if (BT_PERIPHERAL && !BT_CENTRAL)
    	default 1 if BT_PERIPHERAL
    	default 0
    	range 0 BT_MAX_CONN
    	help
    	  Number of concurrent peripheral roles defines how many simultaneous
    	  connections can be created with the device working as a peripheral.
    	  NOTE: the number of central roles is defined as
    	  BT_MAX_CONN - BT_CTLR_SDC_PERIPHERAL_COUNT

    Where it sets different default values based on dependencies. 

    Best regards,

    Edvin

  • In general, what am I trying to achieve is the ability for every module in my app to select the appropriate Kconfig's it needs with the appropriate values. meaning if it needs som zephyr Kconfig to be y it makes it to be y, if it needs some zephyr Kconfig to be n then it makes it be n, if it needs some Kconfig to be 4000, it sets that Kconfig to 4000. This way in the proj.conf of the app I could only set my module's Kconfig to y and get all the relevant Kconfigs it needs from zephyr automatically without me having to set them my self.

    The problem is I didnt find anyway to do that with setting something to n or 4000. The only option I saw is
    adding another config in my Kconfig with the default I want. but when I do that, I dont want to to lose it's prior dependencies. I want to extend it's definition not override it.

    Now I am just trying to understand what is the intended relationship between multiple configs on the same variable. 
    if you define a variable with config somewhere in your app, and then define it again in another place
    in theory there are some options:
    1. The build system would only take one of them into account.
    2. The build system would take both of them into account trying to merge their definitions into 1 and resolving conflicts by taking the values from the last one.

    I know I can achieve the result I want like you showed but I dont want to patch zephyr for every Kconfig I want my module to set a value for.
    I dont understand from your answer, which one do you think it's supposed to be, 1 or 2? 
    if its 1, why dont I have the option just to extend the varilabes defintion in my Kconfig file?

Reply
  • In general, what am I trying to achieve is the ability for every module in my app to select the appropriate Kconfig's it needs with the appropriate values. meaning if it needs som zephyr Kconfig to be y it makes it to be y, if it needs some zephyr Kconfig to be n then it makes it be n, if it needs some Kconfig to be 4000, it sets that Kconfig to 4000. This way in the proj.conf of the app I could only set my module's Kconfig to y and get all the relevant Kconfigs it needs from zephyr automatically without me having to set them my self.

    The problem is I didnt find anyway to do that with setting something to n or 4000. The only option I saw is
    adding another config in my Kconfig with the default I want. but when I do that, I dont want to to lose it's prior dependencies. I want to extend it's definition not override it.

    Now I am just trying to understand what is the intended relationship between multiple configs on the same variable. 
    if you define a variable with config somewhere in your app, and then define it again in another place
    in theory there are some options:
    1. The build system would only take one of them into account.
    2. The build system would take both of them into account trying to merge their definitions into 1 and resolving conflicts by taking the values from the last one.

    I know I can achieve the result I want like you showed but I dont want to patch zephyr for every Kconfig I want my module to set a value for.
    I dont understand from your answer, which one do you think it's supposed to be, 1 or 2? 
    if its 1, why dont I have the option just to extend the varilabes defintion in my Kconfig file?

Children
  • It is not intended that you define a configuration several times (like you did in your example, with TESTING0 defined two times). But you can set the value of a config variable multiple places. E.g. you can set a default value to be 4000, and then you can change it in your prj.conf. The way it works then is that if it is not specified in prj.conf, it will have it's default value. If it is set in prj.conf, then that will overwrite the default value. 

    shlomots said:
    what am I trying to achieve is the ability for every module in my app to select the appropriate Kconfig's it needs with the appropriate values. meaning if it needs som zephyr Kconfig to be y it makes it to be y, if it needs some zephyr Kconfig to be n then it makes it be n, if it needs some Kconfig to be 4000, it sets that Kconfig to 4000.

    I see. You can set some values to be dependent on others, like I showed in my last reply. E.g.:

    config TESTING0
        int "Number for testing"
        default 4000 if TESTING1
        default 1000
        range 0 10000
        help
          Test parameter

    You can also use implications in your configs, like the CONFIG_NCS_SAMPLES_DEFAULT (defined in NCS\nrf\samples\kconfig:

    config NCS_SAMPLES_DEFAULTS
    	bool "Enable NCS sample default settings"
    	default n
    	imply LOG
    	imply LOG_DEFAULT_MINIMAL
    	imply ASSERT
    	imply ASSERT_NO_COND_INFO
    	imply ASSERT_NO_MSG_INFO
    	imply HW_STACK_PROTECTION if ARCH_HAS_STACK_PROTECTION
    	imply RESET_ON_FATAL_ERROR if !DEBUG && !BOARD_NATIVE_SIM && !QEMU_TARGET && !TEST
    	help
    	  Use the default configuration for NCS samples.
    

    So if you add CONFIG_NCS_SAMPLES_DEFAULT=y in your prj.conf, it will enable all the "imply"s as well.

    Best regards,

    Edvin

  • hey, sorry for the delayed response I missed your replay.
    I know I can do this with imply, but with imply I can only set a variables value to y dont I? 
    I cant set it to n or 4000, what do I do if I want to set it to n or 4000?

    I see. You can set some values to be dependent on others, like I showed in my last reply. E.g.:

    this is not a solution for me as I said in previous responses, I dont want to patch zephyr/nrf sdk for each variable that I want to set a new value to. you understand that if we are talking about a zephyr Kconfig, and lets say I want to set n or 4000 to 10 zephyr variables, your solution forces me to patch zephyr for each one, or am I wrong?

  • shlomots said:
    you understand that if we are talking about a zephyr Kconfig

    That wasn't clear to me, no. And you are correct. You can only set them to y using "imply" or "select". And if you are talking about Kconfigs already present in Zephyr/NCS, and not Kconfigs that you are creating yourself, you are correct. You would need to change these default declarations (which you might not want to do). 

    shlomots said:
    your solution forces me to patch zephyr for each one, or am I wrong?

    Yes, and I don't recommend it. Again, I thought we were discussing custom Kconfigs. 

    Best regards,

    Edvin

  • Ok, but does that mean that there is no way to achieve my objective?
    if my module uses zephyr Kconfig variables, and I want there values to be diffrent then y, my only option is to set the proper values from the prj.conf?
    thank you for all your time,
    shlomo

  • As far as I am aware, we have discussed all possible ways to do this. If you want to store different sets of configurations, you can store these in different prj.conf files, e.g configuration_a.conf and configuration_b.conf, and only include one of them at the time.

    You can use the CMake argument -DEXTRA_CONF_FILE=configuration_b.conf to add an extra .conf file on top of prj.conf. This means it will first include everything from prj.conf, and then read configuration_b.conf, which will overwrite the KConfigs from prj.conf. If a Kconfig that is set in prj.conf is not present in configuration_b.conf, then it will be left as it is in prj.conf.

    Best regards,

    Edvin

Related