Meeting 2025-06-24 and also 2025-07-01

[adamgreig]

This is the agenda for the next meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• Nominated issues
• IRC/Matrix logs

[rursprung]

there are some old & empty repos which could probably be archived:

• https://github.com/rust-embedded/patterns
• https://github.com/rust-embedded/template
• there might be more - maybe check the repo overview for repos which haven't been updated in a long time: https://github.com/orgs/rust-embedded/repositories?type=all&page=2

[jamesmunns]

Deleted the two main ones, please nominate any others you find in the future!

[BartMassey]

Want to re-examine the issue of potential "actual" UB in the generated output of svd2rust due to taking references to global storage. I think the plan at some point was to replace the references there with raw pointers, doing explicit raw pointer reads and writes? The relevant issue on the svd2rust Github seems to be #714?

[rursprung]

there's a TF provisioning script for AWS for the WG website: https://github.com/rust-embedded/rust-embedded-provisioning

is this still used? who's paying for AWS at the moment? can't this site "just" be hosted using GH pages which would be for free? (minus the domain name, which still costs, of course)

[jamesmunns]

We discussed, an issue will be written to follow up

[ryanstreur]

Issue created here

[rursprung]

there's a showcase (repo, website) which hasn't been updated in a long time (4 years since the last update to the entries). on the other hand there's the awesome-embedded-rust repo which is much more active and generally being linked to.

would it make sense to unify the two and get rid of one?

[jonathanpallant]

Next face to face meeting for the working group. Oxidize is a potential venue - I can investigate if that is interesting.

[jamesmunns]

If folks are interested in meeting at Oxidize, please reach out to @jonathanpallant, we didn't get a large response in the meeting on July 1st.

[BartMassey]

#838 should probably be picked up again.

[jannic]

Tickets of the week, leftovers from past weeks edition:

(Open from last week)

• Add enter_unprivileged() function cortex-m#594
  Looks like Jonathan already reviewed the code changes. But what about the test case, should it be added to the tests run by CI?

• Clarify usage of #[interrupt] attribute and recommend device crate re… book#386
  Ready to merge? Or better wait for the author to apply the formatting suggestion?

(Open from earlier meetings)

• mmaps: fields coverage svdtools#243
  Is this controversial or can it just be merged? (Current merge conflict is only affecting Cargo.toml and easily fixed.)

• added instructions for finding Meta key on MacOS discovery#584
  Looks sensible - any mac user present to verify this?

• cortex-m-pac crate: standard traits and result handling for Cortex-M targets cortex-m#560
  Had some comments that were resolved 3 weeks ago. Still needs a review.

• HardFaultTrampoline now passes &mut ExceptionFrame cortex-m#515
  Jonathan tried to contact the original author in April, but didn't get an answer yet.

[BartMassey]

As always, thanks huge for this.

[romancardenas]

Rust 1.88 is out and comes with naked functions. Maybe it is interesting to adopt this, especially for functions such as __pre_init, _mp_hook, which are called before RAM initialization.

[jonathanpallant]

Some users will be on long-term support branches of Ferrocene, so it would be good to mark this with a version gate to avoid breaking those users.

[BartMassey]

@jonathanpallant My understanding is that the quarterly Ferrocene updates will not advance the rustc version, since this would require re-qualifying the compiler. Is this correct?

[jonathanpallant]

No, that's not right.

We release a new version of Ferrocene four times a year, and each new release is rebased on a relatively recent upstream release. We then offer 2 years of standard support on every release, and longer if required.

We pull from upstream every business day, and effectively requalify every night using CI (assuming it passes and upstream isn't broken in some way). Four times a year we pass a release on to an external third party (TÜV Süd) for validation and signatures. But, if someone wants to cover the costs of that external work and signing process, we can qualify any upstream stable, beta or nightly that you want.

The earliest Ferrocene release we currently support is 24.05, which is based off Rust 1.76. Those users still have a 1 year standard support left.

[BartMassey]

Thank you!