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

[Tom Rini]

On Sat, Jul 30, 2022 at 07:27:31PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 28 Jul 2022 at 07:20, Tom Rini <trini at konsulko.com> 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?
> > ---
> >  doc/develop/build_configuration.rst | 36 +++++++++++++++++++++++++++++
> >  doc/develop/index.rst               |  1 +
> >  2 files changed, 37 insertions(+)
> >  create mode 100644 doc/develop/build_configuration.rst
> 
> I worry that CFG is confusing as it is too similar to CONFIG. Could we
> have an entirely different prefix, e.g. SYS_? Also, why is a prefix
> needed?

We need a prefix here for consistency.  I don't want to use just SYS_
here as that's not always used for some of the values to be converted.

> I have certainly seen things that are named CONFIG_... but are really
> just SoC values. If they are addresses they should be in the
> devicetree, but perhaps for early code in SPL that is not practical.

I tried to elaborate on this more in the later revs of the document.
But yes, we have some legacy code that's just not going to get a massive
rewrite to use device tree more, but also has an active enough user base
that we aren't just going to drop it.  So long as it's not going to make
life harder in the rest of the code base, this feels like a good enough
compromise.

> Re the revert, why? Are you worried that we are bloating Kconfig too
> much with all these internal SoC settings?

As Pali explained in other threads, there was a problem with the values
in that commit, prior to conversion.  But turning the series of ORs and
shifts into a single magic value made it much harder to see and address.
Yes, if it was written to pull from the device tree, it would have been
easier to read and fix there.  But no one is going to rewrite all of the
core PowerPC code.

> What is the policy on using such things for a board? I would very much
> like to avoid board-specific #defines like this.

The policy is better laid out in later revs of the document I think.

> Is your hope to drop all remaining ad-hoc CONFIGs in this way?

A large chunk, yes.  I'm auditing CONFIG_SYS_* still, but there's
probably going a few hundred symbols that just get resolved this way.

-- 
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/20220731/76668579/attachment.sig>