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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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].