Re: C aggregate passing (Rust kernel policy)

[Kent Overstreet <kent.overstreet@linux.dev>]

On Wed, Feb 26, 2025 at 03:16:54PM -0800, Linus Torvalds wrote:
> On Wed, 26 Feb 2025 at 14:27, Kent Overstreet <kent.overstreet@linux.dev> wrote:
> >
> > This is another one that's entirely eliminated due to W^X references.
> 
> Are you saying rust cannot have global flags?
> 
> That seems unlikely. And broken if so.

No, certainly not - but you _do_ have to denote the access rules, and
because of that they'll also need accessor functions.

e.g. in bcachefs, I've got a 'filesystem options' object. It's read
unsynchronized all over the place, and I don't care because the various
options don't have interdependencies - I don't care about ordering - and
they're all naturally aligned integers.

If/when that gets converted to Rust, it won't be a bare object anymore,
it'll be something that requires a .get() - and it has to be, because
this is something with interior mutability.

I couldn't tell you yet what container object we'd use for telling the
compiler "yes this is just bare unstructured integers, just wrap it for
me (and probably assert that we're not using anything to store more
complicated)" - but I can say that it'll be something with a getter that
uses UnsafeCell underneath.

I'd also have to dig around in the nomicon to say whether the compiler
barriers come from the UnsafeCell directly or whether it's the wrapper
object that does the unsafe {} bits that specifies them - or perhaps
someone in the thread will say, but somewhere underneath the getter will
be the compiler barrier you want.