ABI stability and Rust

ABI stability and Rust

[Andreas Hindborg]

Hi Daniel,

I just wanted to mention that we discussed ABI stability in our
bi-weekly rust subsystem meeting today [1].

Two solutions were discussed:

a) Ship a blessed toolchain for each kernel image you ship. Users
   building out-of-tree modules must use this toolchain.

b) If users cannot use the blessed toolchain, they must link all rust
   code into their module and ensure no rust symbols in vmlinux are called.

Outside of those options, I don't think there are any other solutions. I
would not hedge my bets on rustc getting ABI stability, ever.


Best regards,
Andreas Hindborg



[1] https://hackmd.io/PbZOPV1HTwe0hjZTlDGnmA?view#ABI-compatibility-for-Rust

Re: ABI stability and Rust

[Miguel Ojeda]

On Wed, Apr 2, 2025 at 8:44 PM Andreas Hindborg <nmi@metaspace.dk> wrote:
>
> a) Ship a blessed toolchain for each kernel image you ship. Users
>    building out-of-tree modules must use this toolchain.

Indeed, this is the way at the moment.

> b) If users cannot use the blessed toolchain, they must link all rust
>    code into their module and ensure no rust symbols in vmlinux are called.

We currently don't support this. We could perhaps support it after
some other planned build system changes land, but I wouldn't recommend
planning anything based on it at the moment.

> Outside of those options, I don't think there are any other solutions. I
> would not hedge my bets on rustc getting ABI stability, ever.

There are some related efforts, like crABI, but yeah, I wouldn't
recommend assuming it will ever happen. If it does, and even if we can
use it for the kernel, it would be a long-term thing.

Cheers,
Miguel

Re: ABI stability and Rust

[Greg KH]

On Wed, Apr 02, 2025 at 06:44:10PM +0000, Andreas Hindborg wrote:
> Hi Daniel,
> 
> I just wanted to mention that we discussed ABI stability in our
> bi-weekly rust subsystem meeting today [1].

Linux, for C, does not support "binary api stability" not at all, UNLESS
you build with the same exact toolchain (i.e. your build will be
deterministic that way only.)

I don't see why Rust would be any different here, if you want stability,
don't change the compiler, it's that simple.

Yes, we all know how people/distros have gotten away with changing
compilers over time and the binary api does not change, but that's due
to how the c compilers work over tim.  It's NOTHING that the kernel can,
or should, do here.

So if anyone really cares about this, put the work into the compiler
side, it's not a kernel issue.

> a) Ship a blessed toolchain for each kernel image you ship. Users
>    building out-of-tree modules must use this toolchain.

That's what the enterprise distros, and Android, does today, why is this
not a valid option for them to continue to do?

> b) If users cannot use the blessed toolchain, they must link all rust
>    code into their module and ensure no rust symbols in vmlinux are called.

They are not guaranteed compaibility if they change their C compiler
either, so why would Rust be any different?

> Outside of those options, I don't think there are any other solutions. I
> would not hedge my bets on rustc getting ABI stability, ever.

Then just stick with the same toolchain for the lifetime of the release
they wish to keep stable.  Not anything that we need to worry about,
this is on the external users to care about if they want something crazy
like this.

thanks,

greg k-h

Re: ABI stability and Rust

[Daniel Wagner]

Hi,

On Wed, Apr 02, 2025 at 09:00:02PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 2, 2025 at 8:44 PM Andreas Hindborg <nmi@metaspace.dk> wrote:
> >
> > a) Ship a blessed toolchain for each kernel image you ship. Users
> >    building out-of-tree modules must use this toolchain.
> 
> Indeed, this is the way at the moment.
> 
> > b) If users cannot use the blessed toolchain, they must link all rust
> >    code into their module and ensure no rust symbols in vmlinux are called.
> 
> We currently don't support this. We could perhaps support it after
> some other planned build system changes land, but I wouldn't recommend
> planning anything based on it at the moment.
> 
> > Outside of those options, I don't think there are any other solutions. I
> > would not hedge my bets on rustc getting ABI stability, ever.
> 
> There are some related efforts, like crABI, but yeah, I wouldn't
> recommend assuming it will ever happen. If it does, and even if we can
> use it for the kernel, it would be a long-term thing.

Thanks for the feedback.

For the background: I showed Andreas what we discussed internally what
is missing regarding enabling Rust in our downstream kernels. Besides
the livepatching feature, the question was how deal with the ABI
overtime.

I am not really involved in this topic so far. But I am sure it will
help to move things forward.

Thanks
Daniel

Re: ABI stability and Rust

[Daniel Wagner]

On Wed, Apr 02, 2025 at 08:12:45PM +0100, Greg KH wrote:
> So if anyone really cares about this, put the work into the compiler
> side, it's not a kernel issue.

Yes, this is understood.

> > a) Ship a blessed toolchain for each kernel image you ship. Users
> >    building out-of-tree modules must use this toolchain.
> 
> That's what the enterprise distros, and Android, does today, why is this
> not a valid option for them to continue to do?

I asked Andreas how to deal with external modules which are written in
Rust. What are the requirements, etc. Just a stupid question from
my side.

> > b) If users cannot use the blessed toolchain, they must link all rust
> >    code into their module and ensure no rust symbols in vmlinux are called.
> 
> They are not guaranteed compaibility if they change their C compiler
> either, so why would Rust be any different?

Got it. It's the same problem today exists with C.

> > Outside of those options, I don't think there are any other solutions. I
> > would not hedge my bets on rustc getting ABI stability, ever.
> 
> Then just stick with the same toolchain for the lifetime of the release
> they wish to keep stable.  Not anything that we need to worry about,
> this is on the external users to care about if they want something crazy
> like this.

Okay.