# Meeting 2023-04-19
<!-- Leave your topic starting with ### in the relevant sections below -->

## Critical
<!-- bugs, soundness issues, urgent patches/reviews etc. -->

## Status Reports
<!-- You want to report on something you are working on/request reviews.
Or you want to know the status of something someone else is doing -->

### Update to 1.68.2

Alice: I asked the Android team which upgrade schedule would be most useful for Android.

Boqun: Do we need/want to backport to 6.1?

Miguel: I recreated everything from scratch and checked if anything changed.

Gary: I essentially reviewed `diff -ur ~/.rustup/toolchains/1.68.2-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/ rust/alloc/`

Miguel: Notified distro maintainers about update, some are willing to add a dedicated `rust-kernel` package. Some distros have the current version and we can make a list tracking distros that provide the correct version.
Kernel CI integration, sometimes it might fail, if versions mismatch.

Gary: When will we upgrade bindgen?

Miguel: If someone needs bindgen, then we should update. Regardless we should update at some time.

Gary: Main reason for me is the no-return functions. I would only need a slightly newer version.

Miguel: If we upgrade, we would go to the newest.

Gary: The next rust version will be released soon.

Miguel: I also wanted to speak about that, I will test if 1.69 works. My plan is maybe we could put it into 6.3. I will pick the upgrade now and send 1.69 then. 1.68 is the main upgrade and then we will upgrade step by step.
We could also have two versions, but then we would have to have 2 versions of alloc.

Gary: Actually we could compile the newer alloc with the older version.

Alice: there are other workarounds: E.g. support two rustc versions in CI

Miguel: Some features i.e. `new_uninit` we only depend on, because of `Box`. So maybe we can get a stability promise/it gets stabilized. For the internal features, we might get stability promises, but probably not. We will have to see how long the kernel allows us to only have a single supported version.

Alice: Which are we using?

Gary: https://github.com/Rust-for-Linux/linux/issues/2

Miguel: Other compilers are providing special treatment for the kernel, maybe Rust can do the same. Some people on Rust zulip spoke against this.

Andreas: Why do the people not want to give us the guarantees?

Miguel: I am not sure, some people want to give special treatment. Gcc and Clang do.

Gary: If the kernel uses these special features, other people might also start using them.

Miguel: But they are outside of the picture of this negotiations between the kernel and Rust.

Gary: The only really unstable thing is the smart pointer stuff needed for `Arc`. The problem with them is that nobody is spending time on them at the moment.

## Discussion Questions
<!-- Anything that requires lengthy discussion/more general questions also fit here -->

### `dev` branch and test/CI against it

* [ ] whether and when we should start using [`dev` branch](https://hackmd.io/6dmyDvzKRmCMSwLS6cUc2g)
* [ ] tests we can run on `-dev` branches.

Boqun: What do you guys think?

Miguel: I think we should list the pros and cons:

pros:
- we have earlier testing -- for that we have also different options, the `dev` branch, but we could also have a bot, or use PRs on GH
- people can use it as a base for development

cons:
- a lot of new work

Miguel: What is the difference between `next` and `dev`? This cycle we are a bit late, but in more normal cycles.

Gary: If we have a `dev` branch, then the patches that go in have to be at least somewhat reviewed. It is not going to be a place to put unpolished code.

Miguel: It would only be patches that arrive via the mailing list.

Boqun: Another thing that we could do would be: pushing to `dev` without putting it onto the list first.

Miguel: You want other devs to base their work on that.

Boqun: If we are going to announce something, we could put it there. You can ask people to come and test and help with development.

Miguel: It is not really a place to put patches from the mailing list. It is rather like our current `rust` branch is.

Gary: We can just reuse the `rust` branch.

Miguel: If it is useful for people, then I -- or someone else will do it. I think we could maybe using GH to also make the barrier of entry lower.

Andreas: I think we should encourage people to send incomplete patches to the list, if we want that as the main means of communication.

Gary: We could just use GH PRs for this, reviewing on the list is difficult, PRs are a lot easier.

Benno: I agree with this.

Benno: Asks about email client suggestion

Gary: I use claws mail. Is this what you need?
<details>
<summary>Screenshots</summary>

Claws Mail:

mutt:

</details>

Benno: Yes exactly what I want!

(got lost in discussion)

Andreas: I think rust-dev should be a branch with all patches with decent quality applied.

Boqun: If we have a branch that keeps all the almost-ready patches and it is ok to rebase that. I think this is an advantage over going to the list and manually taking the patches.

Miguel: The `next` and `dev` branch would only be about two weeks apart.

(more discussion)

Consensus: The `dev` branch has value for several people, Boqun will setup the branch.

Miguel will create `rust-dev` branch and we will see what happens.

### Build system, LTO for helpers

Andreas wanted to talk about this

Andreas: Add null block driver, inlining does not work. When compiling something as a module, LTO doesn't work.

Gary: LTO can specify symbols you want to keep.

Bjorn3: A version script should limit the visibilty of the symbols

Andreas: Inlining doesn't work for some symbols

Gary: If the symbol is exported, then it's not considered as used once, and LTO won't inline.

Gary: We could compile rust crate and helpers to bitcode and compile them to a .o, without global LTO

bjorn3: sounds a bit like rustc's thin local lto, where thin lto is applied to all codegen units within a single crate. this is the default in release mode. doesn't apply to rust for linux though as we use a single cgu.

Gary: We essentially want the helpers to be its own CGU

Miguel: Need some build system rework

Gary: upstream crate could specify that a downstream crate depending on it needs to link in a helper.

---
Not discussed:

### Manual `quote!` vs `proc_macro::quote!`

I forgot we had [`proc_macro::quote!`](https://doc.rust-lang.org/proc_macro/macro.quote.html). Gary, why did you decide to create a custom `quote!` in the kernel?

Gary: Unstable + bad hygiene

### Lock guard type split for IRQ save

Gary has a prototype here: https://github.com/nbdd0121/linux/commit/01ae567f6c192bdef2e6e5997769ee2314ff78cd

### `ARef` and `AlwaysRefCounted` safety requirements and documentation

[List discussion](https://lore.kernel.org/rust-for-linux/[e-mail]/) about the documentation of `AlwaysRefCounted`:

> Types that are _always_ reference counted.
>
> It allows such types to define their own custom ref increment and decrement functions. Additionally, it allows users to convert from a shared reference `&T` to an owned reference `ARef<T>`.
>
> This is usually implemented by wrappers to existing structures on the C side of the code. For Rust code, the recommendation is to use `Arc` to create reference-counted instances of a type.
>
> ## Safety
>
> Implementers must ensure that increments to the reference count keep the object alive in memory at least until matching decrements are performed.
>
> Implementers must also ensure that all instances are reference-counted. (Otherwise they won't be able to honour the requirement that `AlwaysRefCounted::inc_ref` keep the object alive.)

#### Implement `AlwaysRefCounted` on Rust types?
Gary brought up this example in the list:

impl AlwaysRefCounted for MyType {
    fn inc_ref(&self) {
        self.refcnt.fetch_add(1, Ordering::Relaxed);
    }

    fn dec_ref(this: NonNull<Self>) {
       let refcnt = this.as_ref().refcnt.fetch_sub(1, Ordering::Relaxed) - 1;
       if refcnt == 0 {
           // Unpublish the pointer from some RCU data structure
           synchronize_rcu();
           // proceed to drop the type and box
       }
    }
}

Why can't this be expressed as this:

impl Drop for MyType {
    fn drop(&mut self) {
        synchronize_rcu();
    }
}

and then use `Arc<MyType>`?

Gary: Drop takes `&mut self`, it's too late to unpublish pointer at this point.

Alice: What about things like `mm_struct` that have several refcounts. (`mmgrab`/`mmdrop` and `mmget`/`mmput`)

## Miscellaneous
<!-- stuff that does not fit into other categories -->

### Rust trademark

Just wanted to bring this to your attention, if you haven't already heard of this: <https://twitter.com/rust_foundation/status/1644132378858729474>

Andreas: After backlash from community this appeared https://blog.rust-lang.org/inside-rust/2023/04/12/trademark-policy-draft-feedback.html

And later this https://foundation.rust-lang.org/news/rust-trademark-policy-draft-revision-next-steps/

Benno: Yes they walked back on that, but wanted to make sure we are aware of this (and maybe get permission, if they decide to restrict e.g. modifying the Rust logo).