Meeting 2026-01-27

[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
• IRC/Matrix logs

[BartMassey]

During our Web Archaeology meeting in December, it became clear that we also need a Bookshelf Archaeology meeting: the REWG Bookshelf could use some love.

It has been traditionally hard to find a date and time to have more than a couple of people be online together for this sort of thing. I'd like to propose something similar to how it worked out last time: have as many people as possible meet and try to work out a work plan, then continue with as much extra help as possible to execute that plan asynchronously.

If you are interested in participating, please share your availability for weekends (Fri Sat Sun) in February. Do indicate your time zone, so that we can try to figure out something that works for everyone who wants to be in on the initial thing.

Any comments on this proposal are welcome. Thanks much!

[eldruin]

I can be there 8-10PM CET (Berlin time) pretty much any Friday, Saturday or Sunday.

[trappitsch]

Any Fri/Sat/Sun, except Feb 20 - Feb 22 works for me after ~8:15pm CET.

[BartMassey]

It's looking like 8-10PM Berlin Time on a Saturday so far (@trappitsch can arrive a bit late no prob). Others chime in if that's a problem. I'm thinking 28 Feb.

[adamgreig]

I'm also happy to attend and generally free any Fri 2100-0200 GMT or most times sat/sun ~1300-0200 GMT.

[BartMassey]

Ok, we have four so far and it looks like Saturday 28 February 8-10PM Berlin Time will work. Thanks all!

[eldruin]

The Rust Week 2026 is coming up soon and I might be able to attend the unconf at least partially. Let's talk about what topics we could discuss or what we could do.

[BartMassey]

I want to work on a plan for providing new versions of some of the Embedded HAL traits we lost in the 0.7 → 1.0 transition. I know they were lost for good and sufficient reasons, but some of them (ADC, for example) are missed. I'd also like to think about what other gaps in that space need filling.

[BartMassey]

I've been kicking around the idea of doing a REWG Google Summer of Code this year, either in conjunction with the Rust GSoC or separately. I need to talk to the Rust GSoC folks about this right away, but let's discuss in the meeting whether we would all be good with this, and whether folks would step up with project ideas in the short term and student mentoring when the time came. The deadline for Mentoring Org applications is 2 February, so we need to decide promptly.

---

Some background: for the first 12 years or so of GSoC I ran a Mentoring Org out of Portland State University that was sort of a "student's choice" organization emphasizing students and projects of value that didn't fit into any other GSoC organization. I mentored and arranged mentoring for perhaps 50 students, many of them doing embedded or embedded-related things. I am confident I can make this happen for this year (assuming we are accepted: it is quite competitive) if we jump on it now.

[BartMassey]

I talked to the folks who run the Rust GSoC today and they would like us to run any Rust Embedded GSoC projects through their org! This is fantastic, as it eliminates a pile of administrative fooling around. Let's talk today about whether we want to do this and try to line up some projects and mentors — time is short.

(BTW, thanks to dngrs for bringing up this idea in a chat we're having about other stuff; I'd been thinking about this for a while, but that conversation got me to actually try to do things about it when the GSoC 2026 announcement came out.)

[BartMassey]

https://github.com/rust-lang/google-summer-of-code contains the current ideas page for Rust GSoC.

(Also meant to thank Jakub Beránek who runs Rust GSoC for making a meeting at short notice and dealing with this, and Jack Huey who helps run Rust GSoC for chiming in.)

[BartMassey]

https://matrix.to/#/#re-gsoc:matrix.org if you want to help out with REWG GSoC projects for 2026!

[thejpster]

To Note

rust-lang/rust#150556 was merged, so nightly now has support for Armv7-R, Armv8-R and Armv7-A running in Thumb mode.

rust-lang/rust#150138 was also merged, adding support for Armv6 in Arm mode and Thumb mode. Thumb-mode atomics on that target will be broken until compiler-builtins is updated to provide the __sync* intrinsics that LLVM emits calls to on that platform.

That's eight new targets. Sorry.

rust-lang/rust#150863 will add two more, for 64-bit Armv8-R, wearing my work hat.

That's:

• thumbv6-none-eabi
• armv6-none-eabi
• armv6-none-eabihf
• thumbv7r-none-eabi
• thumbv7r-none-eabihf
• thumbv7a-none-eabi
• thumbv7a-none-eabihf
• thumbv8r-none-eabihf
• aarch64v8r-unknown-none-softfloat
• aarch64v8r-unknown-none

Question

aarch64-cpu currently doesn't do any QEMU-based tests like aarch32-cpu does. Do people think they are useful? Should we add some?

[BartMassey]

I don't know too much about it, but doing this does seem useful to me. Would it be reasonable to just kind of copy-paste the 32-bit tests and call it a day, or does it take more dev than that?

[jonathanpallant]

That's broadly what we'd do, but using the aarch64-rt run-time (which is developed by Andrew Walbran at Google and not by the Embedded Devices Working Group) and using qemu-system-aarch64.

[spookyvision]

meta: the matrix room topic could use a link to the agendas. Would also suggest to move the meeting datetime and agenda further to the front for increased visibility, after code of conduct

[eldruin]

This seems uncontroversial to me so I have just done it. Feel free to change it back otherwise.

[jonathanpallant]

aarch32-rt/aarch32-cpu PRs pending:

• Adds ARMv6 targets. aarch32#98
• Support thumb-mode Armv7-R, Armv7-A and Armv8-R aarch32#99
• Clippy fixes aarch32#107

[jonathanpallant]

FYI, the Cortex-M Security Extensions (aka TrustZone for Cortex-M) RFC is moving along (rust-lang/rfcs#3884).

[jannic]

Triage

rust-embedded/embedded-alloc#119
→ Boils down to two self.heap.borrow_ref_mut(cs) calls in the same statement. The guard of the first one is not destroyed before the second borrow, so it panics. The solution given should work.

rust-embedded/heapless#640
→ More opinions on the topic could be useful?

Reminder about ongoing voting: #897