# Meeting 2024-06-26
<!-- 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 -->

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

- Is there any way to get a unique piece of const data that the compiler can't inline? I am trying to figure out how to make this work in rust: https://gitlab.freedesktop.org/lyudess/linux/-/blob/rvkms-rework-kms-reg/rust/kernel/drm/kms/plane.rs?ref_type=heads#L196

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

### Change of stewardship of `staging/rust-pci`

Danilo will handle `staging/rust-pci`, we need some admin work on the branch to change permissions.

Miguel to change the github permission, and Danilo to send a PR for the webpage.

### XArray patches status

Quick update: Andreas asked Maíra whether she is OK that Andreas takes over, no response. Andreas will inform Maíra that he will send a new version of the `XArray` patches.

### Allocator API

Brief update & sync

##### Dedicated kernel `Allocator`
- implements own `Allocator` trait and `KBox` / `KVec` types
- treewide replace of `Box<T, A>` with `KBox<T, A>`
- implements `kvec!`, returning `Result<KVec<T, A>, AllocError>` (for the applicable variants)
- TODO: implement `Iterator` for `KVec`
- https://gitlab.freedesktop.org/drm/nova/-/commits/topic/allocator

##### Extending Rust `allocator_api`
- old approach for comparison
- https://gitlab.freedesktop.org/drm/nova/-/commits/topic/allocator_api

* Motivation is to get rid of default flags and have all APIs take a flag.
* Also avoid extension traits and feature flags.

* Should we have completely custom Box and stop using alloc.
* Benno: we're essentially doing an experiment with new allocator_api design that works for more use cases.

* Boqun: Can we have a VBox instead of generic KBox?
* Danilo: I don't see why we want to maintain multiple types of boxes.

* Gary: Can we maybe keep alloc Box + KBox and make Box user default to GFP_KERNEL?
* Allows code reuse between kernel + userspace
* Danilo: is it useful?
* Boqun: Kent wants that for bcachefs
* Benno: When we drop `allocator_api` and extension trait then we don't have try_new anymore.

* Andreas: Rust project goals?
* arbitrary self types and `#[derive(SmartPointer)]`
* I see this as two options: one need unstable features and one not

* Gary: If we make flags assoc type that might work for an upstremable allocator API design.
* () would then work for the allocator without flags.
* No needed for kernel now.

* Consensus: don't want to use `allocator_api`.

* Example of Box is special: https://godbolt.org/z/9Mzqffvrq

Boqun: For `Allocator` trait, maybe s/`[u8]`/`[MaybeUninit<u8>]` for the return types
Boqun: I don't think `Unique<T>` should `impl` `Copy` or `Clone`.
- Seems I have some mis-understanding.
Boqun: `KBox<T>::drop` will need to `drop_in_place` the inner `T`. `Box` is [special](https://doc.rust-lang.org/src/alloc/boxed.rs.html#1240)

Boqun: If we have something like [`Owned`](https://lore.kernel.org/rust-for-linux/ZnCzLIly3DRK2eab@boqun-archlinux/), we could do

// newtype for T alloced from kmalloc
#[repr(transparent)]
pub struct FromK<T: ?Sized>(T);

// newtype for T alloced from vmalloc
#[repr(transparent)]
pub struct FromV<T: ?Sized>(T);

unsafe impl<T: ?Sized> Ownable for FromK<T> {
    unsafe fn ptr_drop(ptr: *mut Self) {
        let ptr = ptr as *mut T;
        
        drop_in_place(ptr);
        
        kfree(ptr);
    }
}

unsafe impl<T: ?Sized> Ownable for FromV<T> {
    unsafe fn ptr_drop(ptr: *mut Self) {
        let ptr = ptr as *mut T;
        
        drop_in_place(ptr);
        
        vfree(ptr);
    }
}

and

type KBox<T:?Sized> = Owned<FromK<T>>;
type VBox<T:?Sized> = Owned<FromV<T>>;

### Device / driver, PCI, `Io` series

Brief (strategy) update

### KMS

Lyude: need a unique address to determine if two things are of the same type by comparing the vtables.

Gary: this sounds like require a generic static, but it suffers from the issue on whether would the symbol be emitted when there're multiple translation units.
- Miguel: We would need to mark explicitly a particular TU to emit it -> `extern static`. (like in C++)

`extern static` (generic)
- Can we try to do it as an extension of https://github.com/rust-lang/rfcs/pull/3635 (`extern static`, non-generic)?

We need to give the Rust project a concrete example like we did for `const_refs_to_static`.

Gary: For vtable specificly, a macro solution might work.

Gary:

static VTABLE: bindings::drm_crtc_funcs = Crtc::<Driver>::FUNCS;

Benno & Gary:

#[vtable(unique)]
trait FileOperations {
    const VTABLE: ... = <construct vtable here>
}

// This can't be generic.
struct Bar;

#[vtable(unique)]
impl FileOperations for Bar {
    
}

that generates

trait FileOperations {
    
}

struct VtableForFoo {
    const VTABLE  ...
}

impl FileOperations for Bar {
    const VTABLE: &'static (Vtable type) = {
        static VTABLE: Vtable type = VtableForFoo::<Bar>::...;
        &VTABLE
    };
}