[RFCv1] doc: develop: Describe using CONFIG vs CFG for values

[Tom Rini]

On Thu, Jul 28, 2022 at 03:34:43PM +0200, Pali Rohár wrote:
> On Thursday 28 July 2022 09:20:46 Tom Rini wrote:
> > Document how and when to use CONFIG or CFG namespace for options.  There
> > are times where Kconfig is not a great fit for our needs, so we want to
> > use the CFG namespace instead.
> > 
> > Signed-off-by: Tom Rini <trini at konsulko.com>
> > ---
> > RFCv1:
> > - This is essentially my idea on how to better handle the problem of
> >   CONFIG values that just don't fit in Kconfig because it makes much
> >   more sense to define them statically for a given SoC or calculate them
> >   from other values, and so on.  One example here would be to revert
> >   c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig") and
> >   re-name these to CFG_SYS_.. instead. Another big example here would be
> >   a global search-and-replace of 's/CONFIG_HPS_/CFG_HPS_/g' as that's
> >   all tool-generated. Not all CONFIG_SYS_ options would get this as
> >   boolean choices are well handled in Kconfig, and that may not be clear
> >   enough in what I wrote here?
> 
> In README is also written:

Ah yes, I forgot to see if the README had anything here.  I'll remove
and incorporate in RFCv2.

>   * 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 based on this statement, proposed CFG_* options should be of second
> category - not selectable by user - right?

Right.

> And this reminds me, that CONFIG_SYS_* option in Kconfig should also not
> be possible to select / change by user or in user's defconfig. This can
> be achieved in Kconfig by _not_ specifying short description (after
> "bool" or "hex" keyword). So maybe this should be also fixed? Or at
> least do not introduce new Kconfig options with SYS_* which can be
> changed?

There is a lot of possible follow-up cleanup work to do, yes.  I gave
one example of an unmigration that should be done, but there's certainly
more.  I'll try and make it clearer in RFCv2 about when it is
appropriate to add CONFIG settings but that aren't configurable.

[snip]
> This change looks good. But I'm not sure how to correctly do it. It
> would be nice to see example, e.g. how to handle it for revert of
> c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig").
> Those are board specific options which are exported and required by both
> u-boot drivers and u-boot arch/cpu code.

I'll probably just start with a revert + sed, and leave further clean-up
to whomever has more time and interest on the legacy platforms, for that
specific example.  For all of the SYS_INIT_SP_ADDR as another example,
I'll probably go with renaming to CFG_SYS_INIT_SP_ADDR and
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR being select'd and
CONFIG_CUSTOM_SYS_INIT_SP_ADDR becoming CFG_SYS_INIT_SP_ADDR directly,
and in board.h until someone has the time and desire to further rectify
something that really shouldn't be board, but rather SoC (and adjusted
based on further options) specific.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220728/7e4599b6/attachment.sig>