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

[Simon Glass]

Hi Tom,

On Sun, 31 Jul 2022 at 05:46, Tom Rini <trini at konsulko.com> wrote:
>
> 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.

We could add it. I feel that people new to the code base will find it
confusing that we have CONFIG and CFG.

>
> > 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.

OK I see.

>
> > 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.

OK.

>
> > 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.

Reviewed-by: Simon Glass <sjg at chromium.org>

Regards,
Simon