Meeting 2024-08-06

[adamgreig]

This is the agenda for today's 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

Announcements

• Saturday 24th August will be the first Discovery MB2 book sprint, join if you're interested in helping to write the new discovery book

[jamesmunns]

I can set up a google sheets for this meeting as well, to remind myself:

gh issue list --limit 1000 --state all | tr '\t' ',' > issues.csv

If we have a list of repos we plan to hit, I can prepare sheets for this

[jamesmunns]

Here's a triage spreadsheet, currently for the /wg and /embedded-hal repos:

https://docs.google.com/spreadsheets/d/1FXEx-VxI29a1GMs8w1VqvxeFCsf7NCdpIKabFt8QsHw/edit?usp=sharing

I'll mark it as writable once the meeting starts.

[adamgreig]

In the end we ran out of time for issue triage, so we'll return to this next week. Thanks for preparing the spreadsheet!

[ryan-summers]

There was a request for an embedded devices WG member to review rust-lang/rust#127766 on Zulip according to @thejpster. There's currently an effort underway to stabilize Arm TrustZone support.

[folkertdev]

my point/ask on zullip is a little broader: compiler features that are useful for embedded are blocked on 2 things: 1) someone needs to do the implementation work, and 2) someone needs to review that work. The embedded WG could, and I think should, take a more active role.

We at Tweede Golf have been getting into doing some of the compiler work. That leaves point 2, the review, and a problem here is that there is kinda nobody in the rust review rotation with active embedded domain knowledge. In practice, PRs for embedded are just not reviewed (in a timely manner) because reviewers don't feel confident about the embedded specifics.

After some discussion with the triage team, we think that it would be helpful for the embedded WG to provide that domain knowledge: just make sure that no vital details about the domain are missed. The standard rust review process can take care of the rest (style, test coverage, etc).

[folkertdev]

I've updated some tests in the compiler.

• migrate thumb-none-cortex-m to rmake rust-lang/rust#128636
• migrate thumb-none-qemu to rmake rust-lang/rust#128639

Two things that folks here might have thoughts on

• the first test compiles cortex-m v0.5.0. That is kind of old, would it be worth it to update to something more recent? Perhaps there are are other things that are worth testing here too?
• the second test uses qemu to run tests, but https://github.com/rust-lang/rust/blob/master/tests/run-make/thumb-none-qemu/example/.cargo/config notes that it uses an incorrect -cpu. How big a deal is that in practice?

[tdittr]

These tests also came up on Zulip, with the question of what the tests are actually trying to test.

[adamgreig]

We discussed this in the meeting:

• It's OK to test on cortex-m 0.5.0 since what we're really testing is the compiler being able to output a working cortex-m binary, not our cortex-m crate, but it wouldn't be a problem to update it or vendor it or perhaps rework the test to not depend on crates at all
• the incorrect cpu isn't a big deal, though if we can now use cortex-m0 for the thumbv6 target then even better

[burrbull]

1. There are several svd2rust PRs need discussion.
   First of all Generate unique id for device peripherals svd2rust#857 and raw_access svd2rust#841.
   Also Use riscv section for RISC-V targets svd2rust#856

2. stm32-rs repo needs more maintainers.
   2a. Often question Release soon? stm32-rs/stm32-rs#997

[adamgreig]

• Generate unique id for device peripherals svd2rust#857 (comment)
• I'll re-review raw_access

[diondokter]

I want to discuss this embedded-storage proposal: rust-embedded-community/embedded-storage#58 (comment)

• Do we agree that the current embedded-storage traits are lacking?
• Do we agree that a unified trait would help?
• Do we think the proposed trait is a step in the right direction?

I'm there in the meeting, but only have time in the first half hour sadly

[adamgreig]

We discussed this at length, some people were in favor of the new trait and others thought it might be best to keep distinct traits for the distinct types of memory, though perhaps polishing the existing ones, and letting the higher-level code (filesystems/databases) handle abstraction. Probably best to read the logs for this one!