[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFJgqgRA3xqt6kBZtsZm11nkg7L=cqJtLovORsvq2FAofZJ0Uw@mail.gmail.com>
Date: Fri, 28 Feb 2025 13:48:27 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: David Laight <david.laight.linux@...il.com>, Ralf Jung <post@...fj.de>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Gary Guo <gary@...yguo.net>,
torvalds@...ux-foundation.org, airlied@...il.com, boqun.feng@...il.com,
ej@...i.de, gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com,
ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)
On Thu, Feb 27, 2025 at 4:18 PM Kent Overstreet
<kent.overstreet@...ux.dev> wrote:
>
>
> Those were big breaks.
>
> In rust there's only ever little, teeny tiny breaks to address soundness
> issues, and they've been pretty small and localized.
>
> If it did ever came up the kernel would be patched to fix in advance
> whatever behaviour the compiler is being changed to fix (and that'd get
> backported to stable trees as well, if necessary).
>
> It's not likely to ever come up since we're not using stdlib, and they
> won't want to break behaviour for us if at all possible.
A minor correction as I understand it; Rust is also allowed
to break for type inference changes, as was the case with the
time crate breakage, according to its backwards compatibility
guarantees. Though that hopefully rarely causes as big
problems as it did with the time crate breakage.
Best, VJ.
Powered by blists - more mailing lists