Re: [PATCH v5 5/7] xen: ifdef inclusion of <asm/grant_table.h> in <xen/grant_table.h>

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.12.2023 15:43, Oleksii wrote:
> On Mon, 2023-12-04 at 11:39 +0100, Jan Beulich wrote:
>> On 04.12.2023 11:34, Oleksii wrote:
>>> If you ( or anyone else ) don't mind, I'll update the patch with an
>>> introduction of HAS_GRANT_TABLE.
>>
>> I won't NAK such a patch, but unless convincing arguments appear I
>> also
>> won't ACK it.
> I am going to disable GRANT_TABLE config for RISC-V ( and PPC? ) by
> providing a separate YAML file ( riscv-fixed-randconfig.yaml ) with the
> following content:
> .riscv-fixed-randconfig:
>   variables:
>     EXTRA_FIXED_RANDCONFIG:
>       CONFIG_COVERAGE=n
>       CONFIG_GRANT_TABLE=n
>       CONFIG_MEM_ACCESS=n # this I'll add in the next patch where asm-
> geneic for mem_access.h is introduced
> 
> And then for riscv*randconfig jobs do the following:
> archlinux-current-gcc-riscv64-randconfig:
>   extends:
>     - .gcc-riscv64-cross-build
>   variables:
>     CONTAINER: archlinux:current-riscv64
>     KBUILD_DEFCONFIG: tiny64_defconfig
>     RANDCONFIG: y
>     EXTRA_FIXED_RANDCONFIG: !reference [.riscv-fixed-randconfig,
> variables, EXTRA_FIXED_RANDCONFIG]
> 
> For RISC-V, I prefer having a separate file for all the
> EXTRA_FIXED_RANDCONFIG because in another patch series [1], I'll
> introduce a large number of disabled configs for randconfig.
> 
> For PPC, I don't think it's necessary to introduce a separate YAML file
> for EXTRA_FIXED_RANDCONFIG. For the time being, it is only necessary to
> disable two configs: CONFIG_GRANT_TABLE and CONFIG_MEM_ACCESS (in the
> next patch of this series).

Why would this be different for PPC and RISC-V?

> If this solution is acceptable to you, can I retain your 'Suggested-
> by'?"

No, please don't. I've replied to Andrew on the other thread - I don't
see why helping just gitlab-CI is desirable. I'm actually surprised
Linux have no solution ready for use, as the underlying problem of not
all settings necessarily being valid to use ought to affect them as
well. Then again perhaps this really only is a transient issue during
arch bringup ... In which case the approach taken here may be fine, but
it still wouldn't be what I suggested. It may then be Stefano or Andrew
who you could consider for such a tag.

Jan