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.kuroc...@gmail.com>
> >>>> ---
> >>>> 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.kuroc...@gmail.com/
[2]
https://lore.kernel.org/xen-devel/d42a34866edc70a12736b5c6976aa1b44b4ebd8a.1701453087.git.oleksii.kuroc...@gmail.com/
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].
