# Meeting 2026-02-18
<!-- 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 -->

- Rust null block series [is out](https://lore.kernel.org/rust-for-linux/[e-mail]/T/#t) :partying_face: Bug reports, Tested-by tags, reviews, etc. are very welcome.

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

Copy from/to maybe user mapped pages:
- [Use Rust intrinsics or kernel `memcpy`?](https://lore.kernel.org/r/[e-mail])

[boqun] I'm writing down my understanding of the abstract of the problem:

Basically we need a `memcpy()` that can 1) not data race and 2) work with external accesses (e.g. from userspace). In my opinion, there are two directions we should go:

1. Using `bindings::memcpy()` to implement a volatile `atomic_bytewise_memcpy()`. <- the approach that we are taking currently in the patch.

2. Using `core::ptr::copy()` or `intrinsics::volatile_copy_nonoverlapping_memory()` in Rust and pretend it won't data race or be mis-optimized and ask for a special case.
* Reduce the necessity of FFI calling.
* Work in practice.
* Extra benefit, we can have an optimizable API that [copy/read/write "at most" ONCE](https://lore.kernel.org/llvm/CAHk-=[e-mail]/).

[Tyr: implement reset logic](https://gitlab.freedesktop.org/panfrost/linux/-/issues/28) design:

- Do we have a concerete API in mind or we should try to mirror the Panthor side logic?
- I guess we only need to cover soft-reset, right? I couldn't find hard-reset handler anywhere on the Panthor side.
- Should this work implement only the API or also include using the API?
- Where should I submit my initial work, ML or send a PR to the gl repo?

### Safe `fn_cast!` and Project Safe Transmute

https://github.com/rust-lang/rust/issues/140803

Miguel: would Project Safe Transmute consider making `fn_cast!` safe for certain subsets, and if so, should we ask upstream Rust to rename to `unsafe_fn_cast!` in that case?

### Roadmap

Benno: categorize, keep the big ones in the roadmap file.

Two kinds: the automatically generated roadmap (from other project goals) and the "further roadmap".

Boqun: following Benno's suggestion, it's better we can group "external" goals (project goals that "point of contact" is not us) that we care most into a prioritized wishlist for example ("Const traits" and "generic const").

#### Already tracked

- In-place initialization.

- Field projections.
+ Recently, we again encountered field projections with `dma_read!` and the need to generalize it for general IO.

- Arbitrary self types

- ...

#### Existing Goals We're Interested in

- `Forget` and `Move`.
+ We want unforgettable guard types for our locks and could take advantage of a `Move` trait to make our types `!Move`.

- Const traits.

- More const generics.
+ Always helps.

#### Wishlist

- `rustfmt`: removing the `//` hack inside imports ("kernel vertical style").
+ Essentially being able to trigger the logic that currently gets triggered when `rustfmt` detects a comment.

- Coherence domains.
+ Not just for the orphan rule, but also to e.g. define inherent methods on a dependency like `core` and `std` do to each other.

- Niche optimizations.
+ At least for Rust `enum`s that contain pointers to aligned objects (e.g. 4 byte alignment in XArray, or to a page, etc.).

- Clippy: `// PANIC: ...`, `// CAST: ...` and `// ORDERING: ...` comments.

- `extern` types.
+ Currently we use `Opaque` (a `UnsafeCell<MaybeUninit<T>>` + `PhantomPinned` for avoiding uniqueness for mutable references), but we need to be careful with `mem::swap` and forces us to take `&self` in certain cases we wouldn't want.

- `-Coverflow-checks=report`.
+ i.e. a new mode that allows to "report and continue" (wrapping), like UBSan and similar tools.

- CFI related improvements.
+ `fn_cast!` macro and `bindgen` improvements to generate the annotation for CFI encoding on structs.

- Support packed types to be aligned or to contain aligned members.
+ And `bindgen` support for it.

- Custom prelude.

- `build_assert!`.
+ Especially ways to fail earlier and/or improve the error messages, similar to [GCC's](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-error-function-attribute) and [Clang's](https://clang.llvm.org/docs/AttributeReference.html#error-warning) `error`/`warning` attribute.

- Specialization for improving the performance of our `alloc` types.
+ And generally leveraging any remaining magic `Box` may have.

- `--emit=noreturn`.
+ We may be able to improve `objtool`, but having that at least as a unstable option for the time being would significantly improve the situation.

- Safe transumations.
+ We may vendor `zerocopy` for now, but long-term we are interested in seeing parts of it make it into the standard library.
+ TODO: Can `fn_cast!` be safe in some cases? It would seem like it, in which case, should we split it into `fn_cast!` vs. `unsafe_fn_cast!`?

- Contracts/better safety comment tools.
+ Perhaps served by external tools.

#### Extra things

- `bindgen`
+ Markus: A solution to convert headers like `include/uapi/linux/input-event-codes.h`.
* Miguel: We would likely need to give extra information to `bindgen`, either via flags on annotations on the C header. But if we need to give annotations in the C header, it may be that it is just better to convert it to an `enum`.
* Danilo: for uAPI headers, changing from macros to `enum` may break C or C++ or other languages using the header.

- Better Macros (maybe just a nice to have)
+ Macro-public-only items (so items that can only be used from *our* macro, but not outside)

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