On Sun, Nov 17, 2024 at 12:48:14PM -0700, Simon Glass wrote:
Hi Tom,
On Fri, 15 Nov 2024 at 07:44, Tom Rini trini@konsulko.com wrote:
On Fri, Nov 15, 2024 at 06:37:18AM -0700, Simon Glass wrote:
Hi Tom,
On Wed, 13 Nov 2024 at 15:20, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 13, 2024 at 09:03:35AM -0700, Simon Glass wrote:
Hi Tom,
On Tue, 12 Nov 2024 at 19:40, Tom Rini trini@konsulko.com wrote:
On Fri, Nov 08, 2024 at 08:23:49AM -0700, Simon Glass wrote:
> It has become more common to use config fragments to extend or adjust > the functionality of boards in U-Boot. > > Propose a format for how to deal with this. It is not implemented as > yet. > > Signed-off-by: Simon Glass sjg@chromium.org
I think that the first problem is that this patch series is an inappropriate method and place to start the discussion.
We had a discussion a year ago but it trailed off.
OK. Still an inappropriate place to resurrect it.
What do you suggest? I am trying to solve the problem, not just talk about it, so patches are often best for that.
Well, in that there's a problem to be solved, it's that buildman makes #include more painful that it should be to use.
Or, we validate config fragments by building them. A requires-buildman solution is not appropriate. That: https://patchwork.ozlabs.org/project/uboot/patch/20241114115049.2070780-2-pa... doesn't use the acpi.config fragment is because of the parsing issue buildman has.
I also think this gets things backwards as the common case is "make", not "buildman". We need more defconfig's that are just base + fragment(s) if they're important enough to be a combination that needs to be tested and work. A board is not a time-expensive part of CI. A pytest run is, a new job itself is.
OK, that would work too. It would also avoid the problem of combinatorial explosion. But I am not seeing people actually doing that, with rare exceptions.
I think it's the exception, not the rule, where config fragments are not being put to use in a defconfig. And that's possibly because not a lot of people seem to know about the #include option, and then when I explain it exists to people the next problem is "Oh, I have to do what so that buildman also works?".
Are you looking for any feature in Buildman for this? This series is intended to fix [1]
Yes, the part of this series that, if I read it right, causes buildman to read the preprocessed config file, rather than the raw defconfig, is what should fix that, as the final patch in the series confirmed.
Are you saying you want a validation solution that doesn't use buildman. If so, why? CI relies entirely on buildman for building things.
Because (a) fragments should be used as a general rule and (b) it will introduce a new failure mode for new platforms, platform added with fragments, whatever-table not updated.
The first 7 patches of this series resolve an issue that you filed. Above you say 'because of the parsing issue that buildman has'. So...should we fix it?
Yes, patches 1-7 are good and I'm leaning towards picking them up for -next soon. They haven't quite had the general 2 week waiting period for others to comment on.
I don't like having fragments in the tree where we don't (at least programmatically) know what board they relate to. At least I think it should be an error to add a fragment with no in-tree defconfig users.
Fragments don't have specific relationships to boards. That's what I keep saying. And we *intentionall* have fragments without in-tree defconfig users too, as I spelled out in another part of this thread.
In any case, I think the file format I have come up with is somewhat reasonable. My main concern with it is that it might greatly increase the CI load.
Yes, but I don't want the thing you're proposing and don't think it will have value and that it will make life harder not easier because of introducing a new CI-only failure mode for submissions.