Hi Tom, On Wed, 19 Jul 2023 at 07:34, Tom Rini <tr...@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 <tr...@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 <tr...@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-kaci...@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-clamo...@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