---
title: "Lang/RfL meeting 2024-09-25"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-09-25
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-09-25
url: https://hackmd.io/ylyTryEBQZCRA1XyZxdHfw
---

# Discussion

People: TC, tmandry, Josh, nikomatsakis, Miguel, Alice Ryhl, Benno Lossin, Xiang Fei Ding, Gary Guo, Matthew Maurer

## Recent sessions

- https://kangrejos.com (sessions & slides to be uploaded very soon)
- https://lpc.events/event/18/sessions/186/
- https://lpc.events/event/18/contributions/1912/
- https://www.youtube.com/watch?v=vWF_zFasiM0

## modversions?

TC: The recent article:

https://lwn.net/SubscriberLink/991062/b0df468b40b21f5d/

...said:

> Torvalds pointed out that there are kernel features that are currently incompatible with Rust; that is impeding Rust support overall. He mentioned modversions in particular; that problem is being worked on. The list of blocking features is getting shorter, he said, but it still includes kernel features that people need.

...which links to:

https://lwn.net/Articles/986892/

Anything we need to think about here?

Matthew Maurer: This is being worked on by me and Sami Tolvanen. There's a table here that has symbol names. Rust symbols are longer, and they don't fit into this table. They're not willing to expand this table since userspace tools do parse it. I'm working on some patches to send upstream to Linux that would support variable length fields and other things.

Josh: I wonder whether there are things we could do to shorten symbol names, e.g. with hashing (that implies some debugging tradeoffs).

MM: That might help, but even if we made things 50% better, there'd still be a huge number of symbols that would exceed the maximums here. The limit is 64 characters. It's easy for polymorphic code to produce symbols that can't be compressed that far.

For background, see:

- https://lore.kernel.org/rust-for-linux/[e-mail]/
- https://lore.kernel.org/rust-for-linux/[e-mail]/

MM: I'm also working on doing stable ABI within a single compiler version using `#[repr(Linear)]`. This is to support vendors building drivers and shipping binaries, and being able to apply those against a kernel that has been updated with security patches.

Josh: Example from the [v0 mangling documentation](https://doc.rust-lang.org/stable/rustc/symbol-mangling/v0.html):

_RNvMsr_NtCs3ssYzQotkvD_3std4pathNtB5_7PathBuf3newCs15kBYyAo9fc_7mycrate
├┘└───────────────────────┬──────────────────────┘└──────────┬─────────┘
│                         │                                  │
│                         │                                  └── instantiating-crate path "mycrate"
│                         └───────────────────────────────────── path to std::path::PathBuf::new
└─────────────────────────────────────────────────────────────── `_R` symbol prefix

Hypothetically, what if we *didn't* include the instantiating crate, and *only* included something like `std::path::PathBuf::new` plus the details of what types it was instantiated for? Advantage: we could then unify those symbols between instantiations.

MM: This might break with per-crate LTO.

Josh: It might break a *lot* of things; there's a lot of complexity here. It seems worth exploring in the future.

## Learning materials

TC: The recent article also says:

> There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn. (See this article for a discussion of how the Rust-for-Linux developers are working to meet this need).

...it links here:

https://lwn.net/SubscriberLink/990619/54bb12eb1a3c796a/

This going well?

Miguel: We want to add a lot of Rust-related resources to:

https://docs.kernel.org/process/kernel-docs.html

Carlos's latest patch: https://lore.kernel.org/rust-for-linux/[e-mail]/T/#u

## Target modifiers

Alice: Flags that affect the ABI:

- https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Changing.20ABI.20soundly.20without.20target.20triple.20explosion/near/467785220

What is the best process for compiler flags and options?

* Should we make a compiler team project goal for Rust?
* "have options needed by RfL that are already supported by LLVM" etc

common concerns are

* mixing compiler flags creates UB, there shouldn't be UB from flags
* you can't build the stdlib with these flags, so how can this work?

but of course neither of these are a concern for the kernel.

Miguel: From the kernel side, the concerns are:

* What to tell kernel architecture maintainers, i.e. how should they approach this kind flag? (especially if they need to request it to the Rust project or if they want to implement it themselves)
* It is not really a hard requirement (although it would be of course very nice) from the kernel that the compiler checks that it is not UB when you mix-and-match CUs.

Josh: Could we add something to the crate hash so that crates built with two different ABI-affecting options won't silently link together and break?

Alice: That would be a good additional check.

MM: Ralf proposing to restrict soft float. Concerned about the direction that implies.

NM: I brought this to the compiler team here:

https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/stabilizing.20compiler.20flags.20for.20Rust-for-Linux

tmandry: It sounds like this needs an RFC with the full story. It doesn't need to handle every use case.

Miguel: I mentioned recently to Ralf the issue about the direction Matthew is mentioning: https://github.com/rust-lang/rust/issues/116852#issuecomment-2346996534

Gary: There are a lot of similarities here to the panic strategy. The linking here already demands many of the same things.

NM: Goal should be to avoid accidental misuse, but not prevent people from solving their problems due to theoretical misuse.

Miguel: Having a way to bypass even those accidental misuse protections could be a good idea, e.g. some people may want to experiment.

## Project goals

https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html

https://github.com/rust-lang/rust-project-goals/issues/116

Alice: We still need to decide on a name for `derive(SmartPtr)`.

Gary: There are discussions here with respect to `asm_goto` and `safe { .. }` blocks. This has the potential to bleed out into a bigger discussion.

Gary: I'm interested in implementation, however would like to know the direction we're heading first.

## Stabilize `const-refs-to-static`

We need to land this first before changes to reference. Otherwise, `reference` doctest will not pass.

https://github.com/rust-lang/rust/pull/129759