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

[Simon Glass]

Hi Tom,

On Wed, 19 Jul 2023 at 07:34, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Jul 18, 2023 at 07:07:58PM -0600, Simon Glass wrote:
> > 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.
>
> I think the message is fine as it clearly says what it does.
>
> > Could we also get some docs in doc/build/gcc.rst or similar?
>
> No, I don't think that makes sense yet.  And looking at that doc, we
> should split that up in to compiler specifics and then a general build
> doc.  Using fragments belongs in the board docs which use fragments (as

Indeed.

+Heinrich Schuchardt perhaps?

> is done in the series which have boards using fragments) and as a
> general "do this to make developing your board easier" that should come
> later once there's more agreement and understanding of what we can and
> should do with fragments, rather than meta-options in Kconfig.

Yes it is that understanding that I am missing.

>
> > > > > 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.
>
> Well, since I'm not letting people bring in fragments until it won't
> make the configs directory even more unmanageable, we have a problem.
> The problem which this patch solves.  And the example I gave above is
> in-tree, except for the final step of "now make this my product", which
> when it's a matter of a new device tree and config, is fine for most
> cases.

My objection is really that this changes / adds behaviour for which
there is no mention in the docs. I didn't even know about this stuff.

>
> > 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
>
> I'm not worried about this at the start. If people start trying to
> enable unique drivers only in fragments, we have a problem. But based on
> all of the proposed uses so far, we shouldn't see unique settings there
> that we need to have compile tested all the time.

OK

>
> > there is no record of what fragments can be built with what, it could
> > get awfully confusing.
>
> Exactly why I want these fragments to be able to live in the board
> directory rather than the top level configs directory.  Honestly, this
> also opens up the possibility of moving the defconfig files from
> configs/ to the board directory and I think that would be really good.

Yes it would be easier, since we can presumably still enumerate them
using MAINTAINERS

>
> > 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.
>
> I'm not sure how buildman will handle fragments, if at all, but that's a
> secondary consideration.  Buildman isn't used by most people and in most
> cases, "make" is, and that supports (and has supported for I don't know
> how many years, off-hand) config fragments.

OK, well if it becomes a problem we can worry about it then.

Regards,
Simon