[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <33A13F26-546B-4CB9-9A4A-367973397CCA@gmail.com>
Date: Wed, 26 Feb 2025 16:26:02 -0800
From: comex <comexk@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
Martin Uecker <uecker@...raz.at>,
Ralf Jung <post@...fj.de>,
"Paul E. McKenney" <paulmck@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>,
Ventura Jack <venturajack85@...il.com>,
Gary Guo <gary@...yguo.net>,
airlied@...il.com,
boqun.feng@...il.com,
david.laight.linux@...il.com,
ej@...i.de,
gregkh@...uxfoundation.org,
hch@...radead.org,
hpa@...or.com,
ksummit@...ts.linux.dev,
linux-kernel@...r.kernel.org,
miguel.ojeda.sandonis@...il.com,
rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)
> On Feb 26, 2025, at 3:16 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> On Wed, 26 Feb 2025 at 14:27, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>>
>> This is another one that's entirely eliminated due to W^X references.
>
> Are you saying rust cannot have global flags?
Believe it or not, no, it cannot.
All global variables must be either immutable, atomic, or protected with some sort of lock.
You can bypass this with unsafe code (UnsafeCell), but then you need to ensure no concurrent mutations for yourself, or else you get UB.
For a simple flag, you would probably use an atomic type with relaxed loads/stores. So you get the same load/store instructions as non-atomic accesses, but zero optimizations. And uglier syntax.
Personally I wish Rust had a weaker atomic ordering that did allow some optimizations, along with more syntax sugar for atomics. But in practice it’s really not a big deal, since use of mutable globals is discouraged in the first place.
Powered by blists - more mailing lists