[<prev] [next>] [day] [month] [year] [list]
Message-ID: <F9C551623D2CBB4C9488801D14F864C6CC7E28A9@ex-mb1.corp.adtran.com>
Date: Wed, 2 Sep 2015 19:16:05 +0000
From: ANDY KENNEDY <ANDY.KENNEDY@...ran.com>
To: "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>
Subject: Kconfig question
Please CC me as I'm not on LKML.
Consider the following Kconfig snippet:
choice
prompt "Partition 1"
default STORAGE_P1_u_Boot
config STORAGE_P1_u_Boot
bool "u-Boot"
depends on ! (STORAGE_P2_u_Boot||STORAGE_P3_u_Boot)
help
RAW storage location of u-Boot.
config STORAGE_P1_App
bool "App"
help
Filesystem where vmlinux, rfs, and application
reside.
endchoice
choice
prompt "Partition 2"
default STORAGE_P2_u_Boot
config STORAGE_P2_u_Boot
bool "u-Boot"
depends on ! (STORAGE_P1_u_Boot||STORAGE_P3_u_Boot)
help
RAW storage location of u-Boot.
config STORAGE_P2_App
bool "App"
help
Filesystem where vmlinux, rfs, and application
reside.
endchoice
choice
prompt "Partition 3"
default STORAGE_P3_u_Boot
config STORAGE_P3_u_Boot
bool "u-Boot"
depends on ! (STORAGE_P1_u_Boot||STORAGE_P2_u_Boot)
help
RAW storage location of u-Boot.
config STORAGE_P3_App
bool "App"
help
Filesystem where vmlinux, rfs, and application
reside.
endchoice
I am using Kconfig for configuring a full system (many App images, one
u-Boot, etc. My Kconfig file is generated dynamically in the Make
system I have written. My intent of the above is to restrict specific
choice options to be mutually exclusive -- I don't want there to be two
partitions named u-Boot in the storage.
I am using an older version (from 2.6.37-rc1) of Kconfig and am
reluctant (scared even) to update.
Kconfig complains about this bitterly. Looking through the code, I see
that if there is a "circular dependency" we reject the entire choice
block (of all circular dependants) from the point of the infraction,
though we still display the entire block of text in the menus. (That is
to say that one cannot select even App from the above due to the
reported circular dependency of u-Boot.)
Is this by design, or is this something that no one thought about
needing/wanting during design/implementation? Would there be a desire
for this change to be implemented into the tip of Kconfig? Would I be
expected to make this change or someone that maybe knows the code a bit
better?
Thanks in advance for any help/advice you are willing to give,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists