[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xm5i4ojrwxubao7sj4w7o564aox73no4v5u5pioofamllvnvwt@444xi7c73qdj>
Date: Mon, 24 Feb 2025 12:24:23 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Theodore Ts'o <tytso@....edu>, Ventura Jack <venturajack85@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, 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, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)
On Mon, Feb 24, 2025 at 04:43:46PM +0100, Miguel Ojeda wrote:
> We also got the question about future subsystems a few times -- could
> they be implemented in Rust without wrapping C? That would simplify
> greatly some matters and reduce the amount of unsafe code. However, if
> the code is supposed to be used by everybody, then that would make
> some architectures second-class citizens, even if they do not have
> users depending on that feature today, and thus it may be better to
> wait until GCC gets to the right point before attempting something
> like that.
If gccrs solves the archictecture issues, this would be nice - because
from what I've seen the FFI issues look easier and less error prone when
Rust is the one underneath.
There are some subtle gotchas w.r.t. lifetimes at FFI boundaries that
the compiler can't warn about - because that's where you translate to
raw untracked pointers.
Powered by blists - more mailing lists