[PATCH V6 2/3] rust: Add PowerPC support

[Ralf Jung]

Hi all,

On 23.02.26 16:31, Miguel Ojeda wrote:
> On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
> <mkchauras at gmail.com> wrote:
>>
>> I think, disabling altivec, fpu and vsx with compiler flag will work.
>>
>> What are your opinion on this?
> 
> It is really up to upstream Rust -- for us, i.e. the kernel, it
> usually doesn't really matter much how things like that are
> accomplished: whether via flags, a built-in target, a custom target,
> etc. However, we need to know what the path to stability is.
> 
> My understanding (but I may be wrong) is that upstream Rust prefer we
> use built-in targets for softfloat instead of disabling via
> `-Ctarget-feature` (and that the other options may go away soon and/or
> will never be stable) -- at least for some cases. For instance, for
> arm64, please this recent change kernel-side regarding `neon` as an
> entry point:
> 
>    446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
> 
> So please ask upstream Rust (probably in their Zulip, e.g. in
> t-compiler or rust-for-linux channels) what you should do for powerpc.
> They will likely be happy with a PR adding the target (or whatever
> they decide) as Alice mentions. And until we reach that minimum
> version (in a year or more), we can use something else meanwhile. But
> at least we will have a way towards the end goal, if that makes sense.
> 
> In case it helps, let me Cc Ralf, Jubilee and Matthew who were
> involved in some of that discussion in the past, plus the compiler
> leads.

Upstream Rust dev here. Indeed we'd strongly prefer if this could use a built-in 
Rust target; we can work with you on adding a new target if that is needed.
The kernel currently uses a custom JSON target on x86 and that's quite the 
headache for compiler development: JSON targets are highly unstable and directly 
expose low-level details of how the compiler internally represents targets. When 
we change that representation, we update all built-in targets, but of course we 
cannot update JSON targets. So whenever possible we'd like to move towards 
reducing the number of JSON targets used by the kernel, not increase it. :)

Kind regards,
Ralf