T-lang/RfL meeting 2024-02-12

--- title: "T-lang/RfL meeting 2024-02-12" tags: ["T-lang", "minutes"] date: 2024-02-12 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-02-12 url: https://hackmd.io/4klpB3vsQbisPkkuCabGqA --- # T-lang/RfL meeting ## Attendance - People: TC, Josh, Alice Ryhl, Adrian Taylor, Lukas Wirth, Sid Askary, remy / lqd, Andreas Hindborg, Miguel, Jakub Beranek (kobzol), Urgau, Boqun Feng, Antoni Boucher, Amanieu d'Antras, Lukas Wirth, nikomatsakis, CE, Trevor, Eric Holk, Tyler Mandry ## Meeting roles - Minutes, driver: TC (TC: Thanks to JT and NM for helping with the minutes, and to NM for assembling an agenda.) (The original agenda document was drafted [here](https://hackmd.io/hEf6bCCwQGO6hXgtmw44fA).) ## Agenda * Compiler compatibility, preview * Optics * Proposal for ongoing interaction * Future deep dive discussions See also: - [Review of desired Rust language features for Rust-for-Linux](https://hackmd.io/r556bZKeSdu0cWwurlHjpw) ## Compiler compatibility, preview RFL currently depends on a [set of nightly features](https://github.com/Rust-for-Linux/linux/issues/2). In principle these features can change in incompatible ways from nightly release to nightly release. Long term, the goal should be that RFL is able to build purely on stable. But in the meantime, RFL project organizers would like to have some amount of stability promises -- e.g., knowing that the RFL codebase will continue to build with the same semantics over some set of releases (note that this does not imply that the unstable features in use can't change, only that they must continue to support the patterns used in RFL). Questions to be resolved: * Is this an accurate summary of RFL's desire? * How long should such a stability guarantee last to be useful (currently, it lasts 1.5 months (i.e., one stable release), which is too short; is 3 months enough? 6 months?). * How can we test it to be sure that we are keeping that guarantee? * How do we coordinate when changes do need to be coordinate? In previous meetings, RFL organizers mentioned [preview features](https://smallcultfollowing.com/babysteps/blog/2023/09/18/stability-without-stressing-the-out/) as one possible solution. This could indeed be great but it would require building consensus around a design for preview features. Before doing that, it would be good to know exactly what RFL's needs are and whether we can do something in the shorter term to meet them. Strawperson proposal: * Some kind of crater setup that tests each Rust PR against RFL codebase to prevent regressions. * RFL builds against latest stable release with RUST_BOOTSTRAP=1. * When a regression is planned, ping RFL folks to coordinate the release in which it will go out. * When RFL users wish to take a new feature gate, RFL users ping Rust to check if it is considered "ok". ### Discussion TC: Regarding the process suggested here, probably we'd want to do something like add a label to the tracking issue for features for which we said it was OK to use them. Miguel: We need that the kernel builds on the stable release, not stable Rust. It's better if we don't use stable features. But we want to establish a minimal version of the Rust compiler with which we can build. NM: You're saying you want to be able to upgrade the compiler without things breaking? Miguel: There are some examples I should provide here. Guaranteeing the compiler builds on stable Rust could be done in several ways, e.g. fully stabilizing every feature Rust-for-Linux needs, stabilizing a subset that Rust-for-Linux needs without finishing stabilization of the full feature, having a mechanism for the kernel to opt in without the features being stable for everyone, or having rolling feature gates for nightly features that remain stable longer than one stable release. As an example, the Linux kernel still supports LLVM 13. TC: Supporting LLVM 13 is an example of continuing to be compatible with an old version, but you also need for code to not break as newer versions are released. These are in a sense two different requirements. Miguel: No tool apart from Rust pins the version in kernel today. Ubuntu is managing this by providing a special toolchain for the kernel; others are not willing to do this. JT: You're tryin to decouple the two problems here. If we solved the problems that prevented you from using stable Rust, that would solve it, because you could choose how quickly to adopt new features. You're tryin to decouple that by saying that you could support a range of versions of Rust rather than just one compiler version, and that such an approach may help distributions. JT: That seems like a reasonable ask and one of the streams of work that should come out of this meeting. That is, how do we solve the problem of allowing you to use a range of Rust versions in a way that's pallatable to RfL, the Rust project, and your distribution partners. NM: I like that suggestion. If we had a long-term support version of Rust, that would also meet the requirement? Miguel: Not sure. We'd need to check what the LTS would do. NM: The best it would get you on its own would be this window. Miguel: We could try to use LTS for LTS kernels. But I'm concerned it would place too many constraints on both sides. Besides, users would expect to be able to use a minimum version. JT: It doesn't necessary solve the distribution problem either. If distros pick the latest stable, that creates problems for you. And if they pick LTS, then that creates pressure for everything in the ecosystem to support that LTS version and not use the latest stable features. We may want a narrower solution for RfL. NM: Agree broadly. We should break this out. Who should be involved in that work stream? Miguel: Perhaps we could defer this to the recurring meetings. --- Miguel: We could have a librfl that would live on the Rust project side. That way, responsibility for keeping that working would fall on the Rust side. JT: For some people, having RfL-specific features/mechanisms in upstream Rust may be unpalatable, but the alternative we should compare this against is that many developers are having their first Rust experiences with nightly Rust, and this is happening on a large scale, giving people an impression of Rust as less stable. Miguel: Exactly right. We should talk about this optics question separately. Miguel: Another alternative would be to change the kernel side. What I mean is that, now, we could stop using the unstable features. But we need to make sure the performance is the same and the ergonomics are good enough. The optics are come into play here, in terms of if the ergonomics are bad. JT: That's going to come into play on a feature by feature basis. We may e.g. be able to come up with workarounds that allow using stable Rust, but we need to consider the ergonomics and other considerations of it. Ultimately, looking at the experiences of projects that have stayed on nightly for many years, there are usually two categories of features. One are the nightly things that they don't know how to live without. Once those are solved, there are other nightly niceties that people are willing to do without. Miguel: Agreed. Another idea would be to have hooks or other ways to customize specific things. Miguel: I also want to mention the CI. I see that crater is mentioned, but we could also have in the CI of Rust something that triggers when breaking the kernel. Then PRs could be blocked on that. Miguel: The preview features that Niko has in the blog post, that may not really solve the issue, though it would be better. Niko: How often in practice do you experience breakage when you move from one pinned release to another? Miguel: Here are our last few upgrade commits: - [c5fed8ce6549 ("rust: upgrade to Rust 1.75.0")](https://git.kernel.org/linus/c5fed8ce6549) - [80fe9e51510b ("rust: upgrade to Rust 1.74.1")](https://git.kernel.org/linus/80fe9e51510b) - [cfd96726e611 ("rust: docs: fix logo replacement")](https://git.kernel.org/linus/cfd96726e611) - [e08ff622c91a ("rust: upgrade to Rust 1.73.0")](https://git.kernel.org/linus/e08ff622c91a) - [a53d8cdd5a0a ("rust: print: use explicit link in documentation")](https://git.kernel.org/linus/a53d8cdd5a0a) - [c61bcc278b19 ("rust: task: remove redundant explicit link")](https://git.kernel.org/linus/c61bcc278b19) - [ae6df65dabc3 ("rust: upgrade to Rust 1.72.1")](https://git.kernel.org/linus/ae6df65dabc3) - [89eed1ab1161 ("rust: upgrade to Rust 1.71.1")](https://git.kernel.org/linus/89eed1ab1161) So there are not so many. That's why I'm comfortable saying that we could put this into the CI for Rust. Most of the breakage is `alloc`. Miguel: `alloc` is something that we'll want to customize ourselves anyway at some point. The features we'd need aren't really libs features; it's the lang features needed to make this work. We could do a prototype to see how many features this would require. JT: The libs and lang teams are aligned on the idea that we should make the standard library less special. We'd like for `alloc` and `std` to be able to be built in stable Rust. For `core`, that's desirable, but more difficult. NM: Elaborating the features needed for `alloc` does seem like a worthwhile discussion. ## Optics and first impressions on kernel side Miguel: For kernel devs not yet convinced about Rust, unergonomic workarounds (e.g., from macros) are a negative point. We try to minimize that sort of thing but we're flexible. Miguel: We need to tell the other parts of the kernel that stability is possible. We don't need this to happen tomorrow. But we need to be able to keep working on this. It's very important to have a recurring meeting. That helps with optics. Then we can truthfully say that the Rust project is willing to work with us and is doing so. JT: +1 on that. A recurring meeting does help with ensuring that people are on board with things. We have a recurring meeting with GitHub that is similar in that regard. When people in the project hit issues, they say, "hey, in your next meeting with the GH folks, could you bring up this pain point?". The fact that we can have that channel is helpful. That's what you're talking about having here, and the kernel and Rust-for-Linux developers will be able to say "hey, in your next meeting with the Rust project can you bring up this pain point?". Miguel: Yes. We want the best optics we can. NM: Totally aligned there. There's no better time than now to start making a better first impression. NM: I'm concerned about being able to align a lot of schedules. Miguel: One question is what should be in the meetings. For us, it should be a project to project meeting. If the Rust project goes and creates a WG, it should be team members who want to solve the problems that the kernel has. Miguel: Regarding RFCs, those can be difficult because of how long they can take. So a WG can help in terms of guiding and driving that process. We need the Rust project to drive the features themselves. Miguel: We've had problems in the past where people thought we were asking for particular features when what we care about is having *some* solution to our use case. Miguel: We're flexible on the times. We can move our own weekly meeting if needed. It's one hour before when this call started, on Wednesday. JT: Looking at what was just posted on the jitsi chat, it's immediately after the T-lang design meeting slot. Sid Askary: Here we have the world's most popular open source operating system saying, "please help us promote your language inside the kernel". It seems like the details can be worked out. But we should address this quickly. NM: The proposal that came up in the thread about using the existing slot every other week sounds good. We should set up a regular sync slot. NM: My main concern is that we'd end up losing momentum by trying to schedule with too many people. JT: Two sugestions. The obvious agenda for a first pass would be going over the currently-used but unstable features. We could talk about feasibility for these. We can talk about who are the people on the RfL side that need that feature and the people on the Rust side that are best able to push forward that feature. JT: Secondly, we should make a Zulip stream where we can discuss the meeting topics and the things that may come up. And we should have a repository for this. That would help with triagebot pulling in issues. TC: We should also add labels, e.g. `I-rfl-nominated`, across other projects. NM: +1. JT: Who will be at RustNation UK? (Alice Ryhl, JT, Adrian Taylor, Sid Askary, Amanieu d'Antras, nikomatsakis, and tmandry indicated they would be attending.) Miguel: Only Alice from our side will be there. It's difficult for people. Miguel: You are also invited to come to our conference, but we know this is hard. https://kangrejos.com/ JT: There's also RustNL in Delft in May. Just offering the opportunity, as I'm willing to take several hours on those occasions. NM: I think we're aligned here. We'll set up the recurring meeting. We should draft a document about how to set up the issues and agenda. JT: Maybe we could have triagebot's agenda generator look for tags in the RfL repo also. *Consensus*: We'll use the Wednesday 1900 UTC slot one week hence as the next meeting. On the lang side (TC), we'll put together a document about how to organize ongoing collaboration in terms of our labels, repositories, and Zulip streams. (The meeting ended here.) ## Ongoing interaction How should the RFL and Rust groups interact on an ongoing basis? Observations: * In-depth discussions about specific features work best with small groups * Participants in both RFL and Rust are busy folks and coordiante calendars is challenging Information that the Rust project wants from RFL: * What new features are you thinking of using but aren't using yet * What are pain points that you cannot find an appropriate feature to solve Information that RFL wants from Rust: * Updates from focused groups on progress so far * this to be done by having the RfL members in the subgroup sync with other RfL members and Rust members sync with Rust members Strawperson proposal: * Dedicated groups pursing particular features (enumerated below, but we can start new efforts easily enough) * Within those groups, Rust folk report back to broader Rust teams * RFL folk report back to broader RFL community * Create a `rust-for-linux` Zulip stream and GH issue tag * Each new issue with `rust-for-linux` tag * Regular RFL-specific "office hours" at a particular time * Rust Project folks make themselves avaiable at this time * If RFL person has a topic they wish to discuss, they open an issue on a `rust-lang/rust-for-linux` github repo * Via automation this opens a topic in the `#rust-for-linux` stream to permit asynchronous discussion * When office hours occur, we will review open tickets, closing them as they get resolved * Larger syncs to be coordinated on an "as-needed" basis, conferences are particularly useful * Starting with Rust Nation, perhaps RustConf in the US? ## Focused discussions Proposed groups for focused discussion. Each of these groups should have 2-4 people, including some from Rust and some from RFL, and have a specific goal. They'll discuss on their own time, establish a goal and timeline, and then try to meet it. ### Arc * People (RFL): Alice Ryhl, XXX * People (Rust): joshtriplett, nikomatsakis (?) Proposed goal: enable Arc-like types that support participation in Linux kernel linked list as well as support for unsized types ### Feature review and bucketing * People (RFL): * People (Rust): joshtriplett ? Proposed goal: stabilize a subset of the features used by RFL Path forward: * bucket unstable features used by RFL into (small, large, research-project) buckets * drive stabilization of the "small" features Initial rough assessment (joshtriplett): https://hackmd.io/r556bZKeSdu0cWwurlHjpw?both ### Features needed for alloc Proposed goal: prototype fork of alloc for kernel use and elaborate unstable features it will need