On Fri, Aug 23, 2024 at 03:09:40PM +0200, Alice Ryhl wrote: > On Fri, Aug 23, 2024 at 2:57 PM Will Deacon <will@xxxxxxxxxx> wrote: > > > > On Fri, Aug 23, 2024 at 02:38:20PM +0200, Alice Ryhl wrote: > > > On Fri, Aug 23, 2024 at 2:24 PM Will Deacon <will@xxxxxxxxxx> wrote: > > > > > > > > On Tue, Aug 20, 2024 at 05:13:58PM +0200, Alice Ryhl wrote: > > > > > On Tue, Aug 20, 2024 at 4:35 PM Will Deacon <will@xxxxxxxxxx> wrote: > > > > > > On Tue, Aug 06, 2024 at 10:01:44AM +0000, Alice Ryhl wrote: > > > > > > > diff --git a/init/Kconfig b/init/Kconfig > > > > > > > index fe76c5d0a72e..d857f6f90885 100644 > > > > > > > --- a/init/Kconfig > > > > > > > +++ b/init/Kconfig > > > > > > > @@ -1909,7 +1909,7 @@ config RUST > > > > > > > depends on !MODVERSIONS > > > > > > > depends on !GCC_PLUGINS > > > > > > > depends on !RANDSTRUCT > > > > > > > - depends on !SHADOW_CALL_STACK > > > > > > > + depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108000 && UNWIND_PATCH_PAC_INTO_SCS > > > > > > > > > > > > Sorry, I didn't spot this in v4, but since UNWIND_PATCH_PAC_INTO_SCS is > > > > > > specific to arm64 and the only other architecture selecting > > > > > > ARCH_SUPPORTS_SHADOW_CALL_STACK is riscv, I can't help but feel it would > > > > > > be cleaner to move this logic into the arch code selecting HAVE_RUST. > > > > > > > > > > > > That is, it's up to the architecture to make sure that it has whatever > > > > > > it needs for SCS to work with Rust if it claims to support Rust. > > > > > > > > > > > > What do you think? > > > > > > > > > > The `select RUST if ...` is going to get really complicated if we > > > > > apply that rule in general. Having options here allows us to split > > > > > them across several `depends on` clauses. I'm not sure it will even > > > > > work, I had issues with cyclic Kconfig errors previously. I also don't > > > > > think it's unreasonable for the architecture to say it supports both > > > > > options when it really does support both; they are just mutually > > > > > exclusive. I also think there is value in having all of the options > > > > > that Rust doesn't work with in one place. > > > > > > > > I'm not sure I follow why this will get really complicated. Isn't it as > > > > straightforward as the diff below, or did I miss something? > > > > > > Hmm. I tried this but I wasn't able to enable Rust with this setup. > > > Even though the deps of RUSTC_SUPPORTS_ARM64 are ok, it doesn't seem > > > to be enabled and I can't find it in menuconfig. I think we need to > > > have a `select RUSTC_SUPPORTS_ARM64` somewhere. > > > > Sorry, yes, my diff was a little half-arsed: > > > > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > > > index a2f8ff354ca6..2f5702cb9dac 100644 > > > > --- a/arch/arm64/Kconfig > > > > +++ b/arch/arm64/Kconfig > > > > @@ -231,7 +231,7 @@ config ARM64 > > > > select HAVE_FUNCTION_ARG_ACCESS_API > > > > select MMU_GATHER_RCU_TABLE_FREE > > > > select HAVE_RSEQ > > > > - select HAVE_RUST if CPU_LITTLE_ENDIAN > > > > + select HAVE_RUST if RUSTC_SUPPORTS_ARM64 > > > > select HAVE_STACKPROTECTOR > > > > select HAVE_SYSCALL_TRACEPOINTS > > > > select HAVE_KPROBES > > > > @@ -265,6 +265,11 @@ config ARM64 > > > > help > > > > ARM 64-bit (AArch64) Linux support. > > > > > > > > +config RUSTC_SUPPORTS_ARM64 > > > > + bool > > > > This line ^^^ should be 'def_bool y'. > > Ah, I see, I guess I learned something today. It also seems to work if > I add `default y`. > > I can change it if you think this is better. I still think there's > some value in having everything in one place, but it's not a big deal. > Either way, it should be temporary for a few kernel releases as we'll > eventually only support compiler versions where this works. I do like moving the reference to UNWIND_PATCH_PAC_INTO_SCS into the arch code, so if you could respin along these lines then that would be great. Thanks, Will
