Rust 1.66.0

[ojeda]

Rust 1.66.0 will be the next version supported by the kernel [1].

Therefore, add rustc-1.66 as a new build environment alongside rustc-1.62 (which can be removed later on when the new version hits mainline), and then move rust-for-linux_rust to it.

Link: Rust-for-Linux/linux#947 [1]
Signed-off-by: Miguel Ojeda [email protected]

[aliceinwire]

Related: #1580

[aliceinwire]

currently testing this.

[ojeda]

Thanks a lot!

[10ne1]

LGTM

Reviewed-by: Adrian Ratiu [email protected]

[aliceinwire]

[writing also here] @gctucker or @mgalka could you enable rustc-1.66 docker image on KernelCI for testing? I cannot test this on staging a starting a test job get stuck because it cannot find the related docker image.

[nuclearcat]

I guess -next not supposed to be buildable by 1.66?
https://storage.staging.kernelci.org/kernelci/staging-next/staging-next-20230108.7/x86_64/x86_64_defconfig+rust/rustc-1.66/logs/build-errors.log
You can see here also builds with rust in general: https://staging.kernelci.org/build/kernelci/branch/staging-next/kernel/staging-next-20230108.7/

[ojeda]

I guess -next not supposed to be buildable by 1.66?

Yeah. Right now, no branch is buildable by 1.66. If we merge Rust-for-Linux/linux#947, then rust-for-linux_rust will be, but at the same time, it will stop being buildable by 1.62. That is why I haven't merged it yet (i.e. the one in the Rust for Linux repo) -- whenever you are ready we can do it. I am not sure which is the best order (or at once) to do so for KernelCI. On the Rust for Linux side, we can do it at any time (for that branch).

Then, after that is merged and we check it is OK, my plan is to submit it to the mailing list (and a matching PR here) and soon after put it into rust-for-linux_rust-next and merge that new PR here. Finally, repeat the same for mainline.

But the above is just what I came up with... If you think KernelCI could handle these "flag day" upgrades in a better way, it would be nice. Ideally, KernelCI could fetch the right environment as given by scripts/min-tool-version.sh (that way we can prepare KernelCI in advance), but I assume that is non-trivial unless the system is designed to do things like bisections anyway.

[nuclearcat]

@aliceinwire maybe we can merge it then? So Rust-for-Linux/linux#947 will be merged too.
Generally rust-1.66 looks ok and working, everything prepared and tested what possible.

[gctucker]

I think it's best if KernelCI is always upgrading rust toolchains to the latest used by Rust-for-Linux, to provide CI as early as possible. As Rust support in the kernel is still in active development, it's expected that things will break in linux-next etc. It's better if KernelCI shows problems that then get fixed, in the end what really matters is that it helps Rust support in the kernel to get tested and working rather than a quiet sea of green results on linux.kernelci.org.

[ojeda]

Yeah, I think it is fine, so let's merge both branches and see if everything goes well. Thanks a lot!

[aliceinwire]

@nuclearcat yes, I was waiting for mgalka to add the rust 1.66 docker build image. Doing last tests with rust 1.66 before merging