Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
On Tue, Jul 11, 2023 at 04:20:46PM -0500, Jason Kacines wrote: > Add support to config fragments (.config) located in the /board > directory. This will allow only base defconfigs to live in /configs and > all fragments to live in their respective device directory in /board/.. > > Signed-off-by: Jason Kacines Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
Hi Tom, On Wed, 19 Jul 2023 at 07:34, Tom Rini 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 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 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 > > > > > > 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
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
On Tue, Jul 18, 2023 at 07:07:58PM -0600, Simon Glass wrote: > Hi, > > On Sun, 16 Jul 2023 at 09:12, Tom Rini 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 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 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 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. > > > > 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. > 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. > 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. > 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
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
Hi, On Sun, 16 Jul 2023 at 09:12, Tom Rini 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 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 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. 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
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
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 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 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? > > 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. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
Hi Tom, On Thu, 13 Jul 2023 at 16:54, Tom Rini 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 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. > > 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? Regards, Simon
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
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 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. 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. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
Hi Jason, On Tue, 11 Jul 2023 at 16:29, Jason Kacines 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? > all fragments to live in their respective device directory in /board/.. Why do we want this? The patch should have a motivation. > > Signed-off-by: Jason Kacines > --- > scripts/kconfig/Makefile | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 12e525ee31..2d97aab8d2 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -99,7 +99,9 @@ endif > %_config: %_defconfig > @: > > -configfiles=$(wildcard $(srctree)/kernel/configs/$@ > $(srctree)/arch/$(SRCARCH)/configs/$@) > +configfiles=$(wildcard $(srctree)/kernel/configs/$@ \ > + $(srctree)/arch/$(SRCARCH)/configs/$@ \ > + $(shell find $(srctree)/board -name "$@")) > > %.config: $(obj)/conf > $(if $(call configfiles),, $(error No configuration exists for this > target on this architecture)) > -- > 2.34.1 > Regards, SImon
[RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
Add support to config fragments (.config) located in the /board directory. This will allow only base defconfigs to live in /configs and all fragments to live in their respective device directory in /board/.. Signed-off-by: Jason Kacines --- scripts/kconfig/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 12e525ee31..2d97aab8d2 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -99,7 +99,9 @@ endif %_config: %_defconfig @: -configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@) +configfiles=$(wildcard $(srctree)/kernel/configs/$@ \ + $(srctree)/arch/$(SRCARCH)/configs/$@ \ + $(shell find $(srctree)/board -name "$@")) %.config: $(obj)/conf $(if $(call configfiles),, $(error No configuration exists for this target on this architecture)) -- 2.34.1
