Meeting 2024-07-09

[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

• svdtools 0.3.17 released

[jamesmunns]

As a note, we decided to go ahead and merge this. We can remove this from this weeks agenda.

[adamgreig]

From @jamesmunns for the cortex-m team:

• Poke the cortex-m team to see if it's reasonable to add a way to eagerly detect when we are missing a "real" linker script, e.g. force a linker error for a missing symbol defined in the c-m-rt link.x and referenced by the c-m-rt crate, so people don't end up with "no loadable section" errors from probe-rs.

• I feel like I've seen people asking about that more recently, not sure if anything has changed, but it feels like something we can do something about, at least in the typical case.

Originally posted by @adamgreig in #772 (comment)

[adamgreig]

RISC-V fallible functions are almost done: rust-embedded/riscv#222

Originally posted by @romancardenas in #772 (comment)

[romancardenas]

• The proposed result module can be found here.
• The module is not part of riscv, but riscv-pac. However, now riscv reexports all the elements in riscv-pac, so in essence it can be seen as a module of riscv. The idea is to isolate traits and the new Error enum from future breaking changes in riscv.

[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.

[ejpcmac]

Would stabilizing special ABIs (like the ones needed for crossing the S/NS TrustZone-M boundary, RISC-V interrupts or naked functions) be a good candidate for that?

[jamesmunns]

@ejpcmac it could be! In general, I think we might want to do something like:

• Start gathering proposals
• Do some curation/prioritization as a working group
• Raise those to the project for tracking

[boozook]

I wrote a proposal issue for cargo. I am free right now and can make some patches for this. But before that, I need the opinion of the members of the working group and some advice.

TL;DR: In case of using user's custom target spec json file, in the build-script context there is not enough info about the target available to configure non-rust compilers (e.g. using cc or bindgen). As well as for rustc, using autocfg crate.
In other words, there is not enough existing env vars for build-script-environment.

[BartMassey]

Status of Discovery Book triage:

• I'm working in https://github.com/BartMassey-upstream/discovery-mb2 . The dev branch should usually contain the latest completed stuff.
• Have restructured as specified.
• Have updated all the code to build cleanly and run with current infrastructure.
• My next task is to go over the text chapter by chapter and clean up.
• @hdoordt is working on a couple of new chapters. He's on a branch of the old book now, but I'll merge his stuff to my repo and consolidate everything shortly.

Open issues:

• Right now the code is mixed in with the book. This works, but makes it awkward for people to do things like grab the code and run it. Worth fixing?

• There's a static globals problem (sigh) with one of the functions in nrf52833-hal. It compiles and works right now, but I've suppressed a compiler warning. I'll file an issue.