-
Notifications
You must be signed in to change notification settings - Fork 99
-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider collecting proposals for 2024H2 Rust Project Goals #775
Comments
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? |
@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.
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:
We generally never should have been doing some of the things that we were doing with |
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 |
@jamesmunns Absolutely agree with your points. The specific use case that finally set me off 🙃 was this: in one of the Discovery Book examples we have a couple of global |
@BartMassey (this is my last response here, let's take the discussion elsewhere): The primary driver for removing |
Maybe #774 is worth considering here. |
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 #773 (comment)
The text was updated successfully, but these errors were encountered: