---
# System prepended metadata

title: Meeting 2024-03-13
tags: [meeting notes]

---

# Meeting 2024-03-13
<!-- 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 -->

### LTO Rust modules with C helpers

https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/LTO.20Rust.20modules.20with.20C.20helpers

Boqun: encountered an issue where `extern inline` doesn't generate anything.

Boqun: encountered an error with .data.rel.ro being placed in `.data.rel.lo`

Andreas: my LTO hack: https://github.com/metaspace/linux/tree/rnull-lto-v6.8-rc6

Boqun: my progress so far: https://github.com/fbq/linux/tree/dev/rust/lto

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

### Dropping our custom `alloc` fork

```rust
trait Allocator {
    type RetType<T, E>;
    type ExtraArg;
    const DEFAULT_ARG: Self::ExtraArg;
    fn map_result<T, E>(r: Result<T, E>) -> Self::RetType<T, E>;
    fn allocate(layout: Layout, arg: Self::ExtraArg) -> Result<u32, std::alloc::AllocError>;
    /// Other functions.
}
```

Benno: What is `RetType`? I find the name not really expressive.
Wedson: We'll change the names :)
Benno: Sure, but what does it is it used for? :)
Wedson: For fallible vs infallible allocators. Hang on.

https://godbolt.org/z/69x53er4v

Trevor Gross: some prior arts
* https://github.com/rust-lang/rust/pull/111970
* https://github.com/rust-lang/rust/pull/117738
* https://github.com/rust-lang/wg-allocators/issues/90#issuecomment-1984981347

Discuss next week after reading more on the background material

### Splitting off the `pinned-init` crate

**Why?:** to make maintanence of the userspace version a lot simpler (ie minimize the differences)

See [here](https://github.com/y86-dev/linux/commits/pinned-init-crate/?since=2024-03-13&until=2024-03-13) for the commits.
My Questions:
- too many small commits?
- println!/pr_info! issue (no access to kernel crate), what to use instead?

Boqun: maybe add a feature for the crate, and the feature decides which print macro to call?

- [CMutex example](https://github.com/y86-dev/linux/commit/bdfc69a2b803af21061a9cb674662a466d5b0fb5) ok to put into tree?

Boqun: I'd not put it in the kernel and create a dedicate crate for this instead, and make it depend on pinned-init.

- what about doctests, would it make more sense to test them as a normal rust userspace library?

- I have some examples with `Arc`, what can I do about that?


Boqun: (general question) I like the overall idea, but am curious about the licensing issue, say someone contributes code in the in-kernel version (which is GPL licensed), can they claim the changes are GPL-only, i.e. you cannot sync it to the userspace crate?

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