Consider collecting proposals for 2024H2 Rust Project Goals

[jamesmunns]

RFC3614 introduced "Project Goals" which are intended to steer the focus and "big picture" of work in the project. The initial batch of goals, "2024H2", have already been selected.

Some external teams, like Rust for Linux, have articulated their desires for the project, and have been included on the "accepted" list.

As a WG, we could consider enumerating any goals we would like to propose to be added for the next selection process, "2025H1", which will begin discussions in October 2024, and will be selected in December 2024.

I'd like to recommend we consider whether there are any coherent goals we can propose to be part of the next project, to support any stumbling blocks in the embedded ecosystem, or to better position Rust as a preferrable choice for embedded development.

Originally posted by @jamesmunns in https://github.com/rust-embedded/wg/discussions/773#discussioncomment-9986197

[BartMassey]

I'd maybe possibly like to add a Project Goal around preserving the ability to use global mutable statics? I know this is controversial, but my personal opinion is that making them effectively unusable because of increasingly fancy memory models is not a great way forward for the Project, especially for the embedded folks. We'd have to work out the specifics of what we wanted, but things like breaking the ability to take a mutable reference to a global static in unsafe code seem especially vexing to me. Thoughts?

[jamesmunns]

@BartMassey not sure if this is the right venue to discuss this either, but I can leave some quick notes, and happy to follow up in chat or somewhere else.

my personal opinion is that making them effectively unusable because of increasingly fancy memory models

To be clear, it's not like there is a fully specified memory model for items like this, and folks are proposing a new one that breaks things. The "current state" is that a lot of these details are entirely underspecified (for all of C, C++, and Rust!), and the fact that they happen to work is leaning on implementation details of different compilers and optimizers, that are allowed to break and change at any time!

I feel very strongly that:

• There are correct ways to implement data structures that are clearly sound inside of Rust, today
• We should do a better job of providing data structures that are usable and well documented. I'm working on doing this in grounded, which I'd like to promote to the WG, and perhaps upstream some of them to the std/core lib as well

We generally never should have been doing some of the things that we were doing with static mut, even with just "rust the language as written", not even considering things like strict provenance, the stacked borrows model, or the tree borrow model.

[ejpcmac]

At work (NXP), we’re currently evaluating Rust to program some of our firmwares. The platform I’m currently working on is based on a Cortex-M33 with a TrustZone-M, and I’ve come to discover that even the base for the TrustZone-M support (cmse_nonsecure_entry and abi_c_cmse_nonsecure_call) are still unstable features.

I’ve seen that the #[cmse_nonsecure_entry] could be transformed to an ABI, and that there are also other specialized ABIs that are available as unstable features. I think that stabilizing those would help a lot of folks in the embedded ecosystem.

[BartMassey]

@jamesmunns Absolutely agree with your points.

The specific use case that finally set me off :upside_down_face: was this: in one of the Discovery Book examples we have a couple of global static mut [u8; N] buffers that will only ever be accessed from one place in a protected context. Right now, we're doing unsafe { &mut buffer } to capture a reference to these. The resulting code is safe according to any memory model I can think of, but the compiler informs me that this code will be rejected in future Rust versions. I'm having a hard time thinking of a reasonable workaround, but I'm probably just missing something?

[jamesmunns]

@BartMassey (this is my last response here, let's take the discussion elsewhere):

The primary driver for removing static mut is that it's very easy to misuse, and there are other unsafe building blocks (UnsafeCell) available. Your specific case might be reasonable! But that's not the only way static mut can be used, so using UnsafeCell (or something like grounded::GroundedCell) might be preferable.

[eldruin]

Maybe #774 is worth considering here.