Re: [RFC PATCH v1 1/1] xen/Makefile: introduce ARCH_FIXED_CONFIG for randconfig

[Oleksii <oleksii.kurochko@xxxxxxxxx>]

On Mon, 2023-12-18 at 18:03 -0800, Stefano Stabellini wrote:
> On Mon, 18 Dec 2023, Jan Beulich wrote:
> > On 18.12.2023 17:07, Andrew Cooper wrote:
> > > On 11/12/2023 3:56 pm, Jan Beulich wrote:
> > > > On 07.12.2023 21:17, Andrew Cooper wrote:
> > > > > On 07/12/2023 5:03 pm, Oleksii Kurochko wrote:
> > > > > > ARCH_FIXED_CONFIG is required in the case of randconfig
> > > > > > and CI for configs that aren't ready or are not
> > > > > > supposed to be implemented for specific architecture.
> > > > > > These configs should always be disabled to prevent
> > > > > > randconfig
> > > > > > related tests from failing.
> > > > > > 
> > > > > > Signed-off-by: Oleksii Kurochko
> > > > > > <oleksii.kurochko@xxxxxxxxx>
> > > > > > ---
> > > > > >  xen/Makefile | 5 ++++-
> > > > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/xen/Makefile b/xen/Makefile
> > > > > > index ca571103c8..8ae8fe1480 100644
> > > > > > --- a/xen/Makefile
> > > > > > +++ b/xen/Makefile
> > > > > > @@ -336,11 +336,14 @@ ifeq ($(config-build),y)
> > > > > >  # *config targets only - make sure prerequisites are
> > > > > > updated, and descend
> > > > > >  # in tools/kconfig to make the *config target
> > > > > >  
> > > > > > +ARCH_FORCED_CONFIG :=
> > > > > > $(srctree)/arch/$(SRCARCH)/configs/randomforced.config
> > > > > > +
> > > > > >  # Create a file for KCONFIG_ALLCONFIG which depends on the
> > > > > > environment.
> > > > > >  # This will be use by kconfig targets
> > > > > > allyesconfig/allmodconfig/allnoconfig/randconfig
> > > > > >  filechk_kconfig_allconfig = \
> > > > > >      $(if $(findstring n,$(XEN_HAS_CHECKPOLICY)), echo
> > > > > > 'CONFIG_XSM_FLASK_POLICY=n';) \
> > > > > > -    $(if $(KCONFIG_ALLCONFIG), cat $(KCONFIG_ALLCONFIG);)
> > > > > > \
> > > > > > +    $(if $(KCONFIG_ALLCONFIG), cat $(KCONFIG_ALLCONFIG); \
> > > > > > +    $(if $(wildcard $(ARCH_FORCED_CONFIG)), cat
> > > > > > $(ARCH_FORCED_CONFIG);) ) \
> > > > > >      :
> > > > > >  
> > > > > >  .allconfig.tmp: FORCE
> > > > > We already have infrastructure for this.  What's wrong with
> > > > > EXTRA_FIXED_RANDCONFIG?
> > > > What I don't understand here is why dealing with the issue
> > > > would want
> > > > limiting to gitlab-CI. Anyone could run randconfig on their
> > > > own, and
> > > > imo it would be helpful if the same issue(s) could be prevented
> > > > there,
> > > > too. Hence my earlier suggestion to have a snippet which can be
> > > > used
> > > > by "interested" parties. And once dealt with in e.g. the
> > > > makefile
> > > > there should not be a need for any overrides in the CI config
> > > > anymore.
> > > 
> > > This is trying to find a solution to a problem which doesn't
> > > exist.
> > > 
> > > RISC-V and PPC are experimental in Xen.  Noone else is going to
> > > come and
> > > randconfig them until they're rather more production ready, and a
> > > prerequisite of that is removing this list of exclusions.
> > > 
> > > Until you can actually find an interested party to comment, I
> > > think this
> > > is just churn for no useful improvement.  If nothing else,
> > > calling it
> > > randomforced.config isn't appropriate given the explanation of
> > > what this
> > > target is used for...
> > 
> > "random" in the name can't possibly be right anyway. Such
> > collection of
> > fixed settings would also be relevant to e.g. all{yes,no}config.
> > Yet
> > that's still not the same as any kind of "default" config, which
> > the
> > two architectures presently kind of abuse for the purpose of
> > defining
> > required-fixed settings.
> 
> One thing for sure, I don't think it would be a good idea to add
> extra
> temporary Kconfig changes like these:
> 
> [1]
> https://lore.kernel.org/xen-devel/cdc20255540a66ba0b6946ac6d48c11029cd3385.1701453087.git.oleksii.kurochko@xxxxxxxxx/
> [2]
> https://lore.kernel.org/xen-devel/d42a34866edc70a12736b5c6976aa1b44b4ebd8a.1701453087.git.oleksii.kurochko@xxxxxxxxx/
> 
> 
> I agree with Andrew that RISC-V and PPC are experimental so whatever
> works to enable them to make progress on this issue with a small
> effort
> is sufficient. I would be happy with a quick respin of this series
> following the gitlab-ci approach. This is good enough.
> 
> And I think that having some sort of fixed seed (seed.config?) for
> randconfig would also be fine and potentially more reusable.
> 
> But I think Oleksii should go forward with whatever approach he
> prefers
> and he is more comfortable with, as long as it is not [1] and [2].
Despite the fact that I am still comfortable with both approaches,
let's stick to the approach that requires minimal effort. For the time
being, let's update patch series [1] with the GitLab CI approach and
revert to the current patch if there are more cases where these changes
are required. Thank you, everyone, for your feedback.

[1]
https://lore.kernel.org/xen-devel/cover.1701453087.git.oleksii.kurochko@xxxxxxxxx/