# Meeting 2024-07-24
<!-- 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 -->

### Alloc Module (Allocator API)

#### General Update
- MM patches: `krealloc()`, `vrealloc()`, `kvrealloc()` now work exactly the same way, which unifies Rust's `Allocator` implementations; additionally it removes the need for the `old_size` parameter of `Allocator::realloc`
- work on a follow up series to properly shrink and grow buffers in `vrealloc()`, i.e. allocate and map additional pages, unmap and free unused pages
- rename to `Box<T, A>` / `Vec<T, A>` with type aliases `KBox<T>`, `VBox<T>`, `KVBox<T>`, etc.
- in combination with dropping `&self` arguments from `Allocator` functions, this leads to cleaner code and gets us rid of `::new_in` / `::new_alloc` kind functions
- Maintainer Entry for Alloc Module

RUST [ALLOCATOR API]
M:      Danilo Krummrich <[e-mail]>
L:      [e-mail]
S:      Maintained
F:      rust/kernel/alloc.rs
F:      rust/kernel/alloc/

#### Patches
- Alloc: https://lore.kernel.org/rust-for-linux/[e-mail]/
- MM (merged): https://lore.kernel.org/rust-for-linux/[e-mail]/

##### API difference from Rust API

Gary: Other allocators in the future may need the "old size" parameter. It's important to be consistent with Rust alloctor API.
Danilo: We can re-introduce "old size" in the future if we really need.
Gary: We want to know whether the (memory?) users know the size information, and should be given to the allocator, and this could drive the changes in Rust upstream allocators.
Danilo: The goals are different, whether it's having a kernel allocator solely or it's to make an example for Rust upstream.
Miguel: How many allocators do we expect to have, i.e. how big of a change we expect to have to do later on if needed?
Danilo: Three, and maybe that's all.
Miguel: And the other way around: if we don't change it now, do we already agree to change later if needed?
Gary: The allocator API and implementions should be relatively stable, so it won't hurt to introduce the parameter.
Gary: https://doc.rust-lang.org/stable/alloc/alloc/trait.GlobalAlloc.html#method.realloc you need to get alignment from the old layout.

Rust GlobalAlloc's realloc function:

unsafe fn realloc(
    &self,
    ptr: *mut u8,
    layout: Layout, // <- contains old size & alignment
    new_size: usize
) -> *mut u8

Alignment:
Gary: If user asks for 768 bytes + 256 alignment, would this allocate correctly

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

##### Self type for allocator?

Would kmem_cache count?

* Maybe should be a different type

Danilo wants to use `Allocator` without having instance to be passed to `new_in`

Gary: This should allow self type without the issue of `new_in`:

impl<T, A: Allocator> Box<T, A> {
    fn new_in(t: T, a: A) -> Result<Self>;
}

impl<T, A: Allocator + Default> Box<T, A> {
    fn new(t: T) -> Result<Self> {
        Self::new_in(t, Default::default())
    }
}

Some potential future work if allows self type:

struct Kmalloc;

trait Allocatable<T: ?Sized> {}

impl<T: ?Sized> Allocatable<T> for Kmalloc {}

struct KmemCache<T> {
    _p: core::marker::PhantomData<T>,
}

impl<T> Allocatable<T> for KmemCache<T> {}

impl<T, A: Allocator> Box<T, A> where A: Allocatable<T> {
    fn new_in(t: T, a: A) -> Result<Self>;
}

Alice: Can't use non-ZST because it is not compatible with `#[derive(SmartPointer)]`.

Consensus: Not to use self

### `#[unique]` in vtable

Gary: I have a WIP here https://github.com/nbdd0121/linux/tree/vtable-wip

#[vtable]
trait Foo {
    #[unique]
    const VTABLE: &'static Vtable = &Vtable {...};
    //             ^ required       ^ required
}

#[vtable]
impl Foo for Bar {
    #[unique]
    const VTABLE: &'static Vtable;
    //             ^ will be unique
}

Waiting for Miguel to send syn :)

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

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

### Binder dependencies

I hope we can get a bunch of them in for 6.12 :)

- Linked list
- Red/black tree
+ Boqun wants to check offline.
- Shadow-call-stack
- File abstraction
+ One of the patches had to get the Reviewed-bys dropped, would be nice to get that one reviewed again.
- VMA
- Tracepoints
+ Steven is happy to take it through his tree.
+ Gary to review

### Miscdevice

Alice is working on an out-of-tree driver that will use miscdev. I will write abstractions and share them, but someone else will need to come up with a use-case before they can be merged.