Meeting 2025-09-23

[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

[jamesmunns]

I spoke with @BartMassey and some of the other project folks (Jack Huey, Josh Triplett) at Rust China Conf, and we discussed forming embedded subteams for T-Libs (potentially adopting/upstreaming work on embedded-hal, embedded-hal-async, embedded-io, etc.) and for T-Docs (potentially adopting/upstreaming work on the embedded rust book, rustonomicon, discovery, etc.).

We've informally discussed this at the last two all-hands/unconfs, and as far as I remember, there was positive sentiment from both project and WG folks, so, there's nothing to it but to do it!

The "todo list" for this is:

• Get consensus from the WG libs team and/or WG resources team that we want to do this, or see if there are any concerns
• Open issues with T-Libs, T-Docs to discuss, iron out any details about forming the subteams
• Open teams PRs to found the new subteams

[jonathanpallant]

As I understand it, T-Libs is extraordinarily busy already, so we should make sure this doesn't give them any extra work to do.

[jamesmunns]

I don't think this would give them any extra work, the expectation would be that we "staff" a subteam that is responsible for the things we upstream, IMO it would basically be 1:1 with the current WG libs team's members and responsibilities.

[adamgreig]

Conclusion from this meeting was we'll open some RFCs to discuss and vote in the HAL team (embedded-hal and perhaps critical-section) and resources team (embedded book, discovery book).

[jamesmunns]

I hadn't received any nominations for Project Director, so I nominated two people:

• Bart Massey (ewg member)
• Jack Huey (Rust Project member, former Rust Council member)

The nomination conversation is here: #council > 2025 project director elections @ 💬, election is in 2 weeks, if you have any positive or negative feedback on any of the nominees, please feel free to share as described in the zulip thread!

[BartMassey]

I really want to talk about the link.x / memory.x situation in the microbit-v2 stack in particular. I want it in the general meeting because I think there are some larger policy issues for arbitrary platforms:

• What should "officially" provide link.x? The architecture / runtime crate (cortex-m / cortex-m-rt)? The PAC crate? The HAL crate? The BSP crate? None of the above?
• Same question for memory.x
• If the user wants to provide their own link.x or memory.x that overrides a provided one, is there an "official" way to do that? What is it?
• If multiple link.x or memory.x are present, how is this currently "officially" resolved? Is this how it should be?

Maybe some / all of these questions could be answered here; maybe there's even a document somewhere that I am missing. If not, I suspect it might be useful to talk about them.

[jonathanpallant]

My thoughts:

What should "officially" provide link.x?

The $arch-rt should provide a default linker script by placing it somewhere under $TARGET_DIR and adding that directory it to the linker search path.

Same question for memory.x

This should be the crate that knows precisely how much RAM and Flash the application can use. You could put this in a BSP, but often people need to override it (if they use a boot loader, etc), so I generally prefer to leave an example in the BSP and let people add it to the package that contains the binary crate(s).

If the user wants to provide their own link.x or memory.x

The user is responsible for supplying memory.x if they are using $arch-rt (or, as above the BSP might do it, but then it's not easy to override).

If the user doesn't want to use the link.x supplied by $arch-rt then they must supply a file with a different name and tell their binary package to pass the name of that script to the linker.

- println!("cargo:rustc-link-arg=-Tlink.x");
+ println!("cargo:rustc-link-arg=-Tmy_custom_script.x");

Then the presence of link.x in the linker search path doesn't matter, and we don't need to remove it.

[BartMassey]

Thanks!

I am confused about what is happening in the current stuff. I am doing some investigation and working on a document: will put stuff here when I understand more.