[U-Boot] a couple questions about "CONFIG_*" variables and the whitelist

[Robert P. J. Day]

  more random questions about stuff ... i see in the top-level README
the explanation:

  "There are two classes of configuration variables:

  * Configuration _OPTIONS_:
    These are selectable by the user and have names beginning with
    "CONFIG_".

  * Configuration _SETTINGS_:
    These depend on the hardware etc. and should not be meddled with if
    you don't know what you're doing; they have names beginning with
    "CONFIG_SYS_".

so, perhaps put another way, regular CONFIG_ variables represent
things that a user has the right to configure to affect the end
result, while CONFIG_SYS_ variables represent values tied somehow to
the underlying hardware that u-boot *needs* to know to function
properly on that hardware? is that a remotely accurate description?

  but that's not a really hard-and-fast rule, is it? as one example
from cmd/Kconfig:

  config SYS_PROMPT
        string "Shell prompt"
        default "=> "
        help
          This string is displayed in the command line to the left of the
          cursor.

obviously, the user has the right to set the prompt to whatever he or
she wants, and i'm sure there are other examples. so the distinction
between those two classes of config variables is not as sharp as the
README suggests, is it? or am i misreading the explanation?

  second question -- i'm pretty sure the standard policy is that *any*
config variables that start with "CONFIG_" are supposed to be defined
somewhere in a Kconfig file, correct? given the history of u-boot,
this clearly isn't true, but in a perfect world, it would be, yes? so
that if one wanted to define some local macro names in a header file
or something, it should never start with the prefix "CONFIG_" unless
it comes from the Kbuild structure. at least that's the standard i
remember from the linux kernel.

  now the whitelist -- i'd never looked at it before, read the first
part of scripts/build-whitelist.sh, so apparently, the whitelist
represents all of the "CONFIG_"-prefixed variables found scattered
throughout the code base, or constructed via CONFIG_SYS_EXTRA_OPTIONS.
and i can see there are over 8,000 of them. yeesh.

  however, given that CONFIG_SYS_EXTRA_OPTIONS is deprecated, and if
one follows the rule i mentioned earlier (that CONFIG_ prefixed
variables should always be defined in a Kconfig file), in a perfect
world, that whitelist would be empty, would it not?

  and, finally, i'm currently digging through the mtdparts code, and
noticed that "CONFIG_MTDPARTS" is in the whitelist file, but there is
no Kbuild entry "config MTDPARTS", so i did a quick grep to see:

$ grep -r CONFIG_MTDPARTS *
include/configs/sheevaplug.h:#define CONFIG_MTDPARTS		\
include/configs/sheevaplug.h:	"=ttyS0,115200 mtdparts="CONFIG_MTDPARTS	\
include/configs/sheevaplug.h:	"mtdparts="CONFIG_MTDPARTS
include/configs/iconnect.h:#define CONFIG_MTDPARTS \
include/configs/iconnect.h:	"mtdparts="CONFIG_MTDPARTS		\
include/configs/guruplug.h:#define CONFIG_MTDPARTS	\
include/configs/guruplug.h:	"mtdparts="CONFIG_MTDPARTS					\
include/configs/guruplug.h:	"mtdparts="CONFIG_MTDPARTS
include/configs/nsa310s.h:#define CONFIG_MTDPARTS \
include/configs/nsa310s.h:	"mtdparts="CONFIG_MTDPARTS \
include/configs/ib62x0.h:#define CONFIG_MTDPARTS \
include/configs/ib62x0.h:	"mtdparts="CONFIG_MTDPARTS					\
include/configs/dockstar.h:#define CONFIG_MTDPARTS		"mtdparts=orion_nand:1m(uboot),-(root)\0"
include/configs/dockstar.h:	"mtdparts="CONFIG_MTDPARTS \
include/configs/goflexhome.h:#define CONFIG_MTDPARTS \
include/configs/goflexhome.h:	"mtdparts="CONFIG_MTDPARTS \
scripts/config_whitelist.txt:CONFIG_MTDPARTS
$

  the above suggests that CONFIG_MTDPARTS is an entirely local
variable in a small number of header files, whose scope is never seen
outside each of those header files. in that case, it would seem
inappropriate to have used that name for that variable, since it gives
the impression of being part of the Kbuild structure. i'm not
suggesting changing any of that (or maybe i am :-), it just seems
silly that using that name causes that variable to end up in the
whitelist file for no obvious reason.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================