[RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../

[Simon Glass]

Hi,

On Sun, 16 Jul 2023 at 09:12, Tom Rini <trini at konsulko.com> wrote:
>
> On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 13 Jul 2023 at 16:54, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote:
> > > > Hi Jason,
> > > >
> > > > On Tue, 11 Jul 2023 at 16:29, Jason Kacines <j-kacines at ti.com> wrote:
> > > > >
> > > > > Add support to config fragments (.config) located in the /board
> > > > > directory. This will allow only base defconfigs to live in /configs and
> > > >
> > > > Does this mean defconfigs?
> > >
> > > This looks like it would cover defconfig files too, but the initial
> > > motivation is config fragments.  See
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-5-clamor95@gmail.com/
> > > for another example.
> > >
> > > > > all fragments to live in their respective device directory in /board/..
> > > >
> > > > Why do we want this? The patch should have a motivation.
> > >
> > > I've asked a few people to look in to this because we have a lot of
> > > cases today of N _defconfig files where we could really instead have 1
> > > _defconfig file and N config fragment files.  But I do not want them
> > > living in the top level configs directory as that will get even more
> > > unmanageable.
> >
> > OK I see, thank you. The patch still needs this motivation though.
>
> So you're saying you want the message re-worded?

Yes, to explain why.

Could we also get some docs in doc/build/gcc.rst or similar?

>
> > > What's not in this patch (and not an ask at this point) is figuring out
> > > how buildman could handle "foo_defconfig bar.config" as the required
> > > config target.
> >
> > Indeed. Also, should they appear in the boards.cfg list?
>
> I doubt it? I'm not sure yet how we address getting buildman to know
> about valid additional combinations. Take the example of something like:
> som_vendor_carrier_defconfig + som_vendor_imx7_som.config +
> emmc_boot_instead.config + customer_production_tweaks.config
>
> How would you want buildman to know about that? Does it even really need
> to, on the other hand?  And that's not I think an uncommon example, it's
> just splitting colibri_imx7_emmc_defconfig in to how it would be used by
> someone taking that carrier+som to production, with their own
> touchscreen and a few other tweaks in the dtb that needs to be passed to
> linux.  Or the mnt reform with whatever SOM/COM you happen to have for
> it.

Well firstly we should only worry about things that are in-tree.

The thing is, if we don't validate that the configs at least build,
then someone could change a config (anywhere in Kconfig or in a 'base'
defconfig) and break the build for these 'add-on' configs. Also if
there is no record of what fragments can be built with what, it could
get awfully confusing.

I would suggest an interface where you can query which fragments are
available for a board, and that buildman support building them. For
that to work, we need some sort of structure. For example the config
fragment could have a line listing the defconfig / .config filename it
is intended to augment.

Regards,
Simon