On 9/13/25 1:37 PM, Miguel Ojeda wrote:
On Sat, Sep 13, 2025 at 7:14 PM Joel Fernandes <[email protected]> wrote:

I am not alone in that opinion.

Hmm... I am not sure how to read this.

This should be first-class in a (systems) language, built into
the language itself?

On this particular point, and *only* this point: some time around
mid-2025, I started wondering out loud, "shouldn't Rust have some
built-in understanding, in the language/compiler itself, of the
concept of pinned memory?"

Because, after doing a modest bit of Rust for Linux coding, I was
struck by "Rust is a systems programming langauge", vs. "systems
programming often involves DMA (which generally pins memory)".
And the other observation is that pin-init discussions are some
of the most advanced and exotic in Rust for Linux. These things
don't go together.

So it seemed like this is a lesson that Rust for Linux has learned,
that can be taken back to Rust itself. I recommended this as a
non-urgent Kangrejos topic.


I would suggest taking a look at our website and the links there (like
issue #2) -- what we are doing upstream Rust is documented.

...and my question was asked before reading through issue #2. So your
and Danilo's responses seem to be saying that there is already some
understanding that this is an area that could be improved.

Good!

I believe "issue #2" refers to this, right?

   https://github.com/Rust-for-Linux/linux/issues/2

That's going to take some time to figure out if it interects
what I was requesting, but I'll have a go at it.


(Danilo gave you a direct link, but I mention it this way because
there are a lot of things going on, and it is worth a look and perhaps
you may find something interesting you could help with).

except to satisfy paranoia

Using unsafe code everywhere (or introducing unsoundness or UB for
convenience) would defeat much of the Rust for Linux exercise.


Yes. It's only "paranoia" if the code is bug-free. So Rust itself
naturally will look "a little" paranoid, that's core to its mission. :)


thanks,
--
John Hubbard

Reply via email to