# Meeting 2022-10-18

## Table of Content

- [x] [Occasional CI Problems](https://hackmd.io/2ZRxjAuKROG-vLzv8ZoiNw?both#Occasional-CI-Problems)
- [x] `pinned-init` merge?
- [x] [(vincenzopalazzo) Trace async like Tokio console](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/crashdump-debugging.20state.20of.20the.20art)
- No news from the Async team, I will try to talk with some guys during the next meeting
- [ ] [(vincenzopalazzo) kpro-macros](https://hackmd.io/2ZRxjAuKROG-vLzv8ZoiNw?both#kpro-macros)
- [ ] [Draft idea and implementation](https://hackmd.io/JWFlyOd2T1mLpPiXBi1Uog)
- [x] async roadmap

## Occasional CI Problems

Benno: Can we fix these easily?

Benno: has there been an analysis?

Miguel: We have this happen many of times. Some times it fixes by itself. Hoping that the update to 6.1 would fix the issue. I can take a look. Might be related to our configs. Move to defconfig and we will be in a more popular configuration.

## `pinned-init` merge
Latest changes:
- back to declarative macro + convenience attribute macro.
- the attr macro actually does an important parsing step: separating `impl_generics` and `ty_generics` and isolate the `where` clause
- better docs
- prevention of `Drop` and `Unpin` impls
- `PinnedDrop`
- other small changes (the explicit `PinInitClosure` type is gone)

Benno: Is there anything missing for a merge?

- maybe making `Arc::pin_init::<core::convert::Infallible>(thing)` less verbose? (e.g. using the never type? `Arc::pin_init::<!>(thing)`)

Gary: need time to go through it. Already pointed out: verbosity with turbofish. `!` improves things, but still not ideal. langchange: Maybe some way to add a fallback to an inference variable./change `?` behavior.

Benno: `try_` variant accepting arbitrary error. `pin_init` would require `Infallible`.

Gary: two macros: `init!` forces `Infallible`/`kernel::Error` and `try_init!` would support any error.

### syntax bikeshed:

let _: impl Init<Struct, Infallible> = init!(Struct {
    a: 0,
    b: new_mutex!(),
})

Maybe let this default to `kernel::Error`

let _: impl Init<Struct, kernel::Error> = try_init!(Struct {
    a: 0,
    b: new_mutex!(),
})

and this for custom error?

let _: impl Init<Struct, CustomError> = try_init!(Struct {
    a: 0,
    b: new_mutex!(),
}? CustomError)

try_init!(Struct {
    a: 0,
    b: new_mutex!(),
}) /* impl Init<Struct, _> */.or();

let _: impl Init<Struct, CustomError> = try_init!(? Struct {
    a: 0,
    b: new_mutex!(),
})

Benno: I will implement the defaulting to `Infallible` and `kernel::Error` with `? <Error>` for custom errors at the end.

Gary: Maybe rename `#[pin_project]` -> `#[pin]`.

Gary: Maybe `proc_macro` can have a function to parse a token stream into another token stream.

Benno: add a macro to automatically implement custom init types?

Boqun: Let's not make it more magic, as it is also used not often.

Miguel: original idea was: drivers should be safer to implement. macros are fine, if they buy us something for drivers.

Consensus: defer to when we have more uses of this.

## kproc-macros

### Problem

Write a macros is painful? maybe yes, but it is also so powerful, so with kproc-macros https://codeberg.org/vincenzopalazzo/kproc-macros I'm trying to propose a parse that return a usable AST to generate other rust code.

#### Status

- [ ] [Design Document (draft idea)](https://hackmd.io/@rust-for-linux/H1n-4Vd7j)
- [ ] [Draft implementation](https://hackmd.io/2ZRxjAuKROG-vLzv8ZoiNw?both#kpro-macros)

Benno, Gary, Miguel: this looks a lot like `syn`.

## `async` roadmap

https://hackmd.io/HiJs8RMZSBmQNJoWHcH3Tw

Boqun: At some point rust async runtime might serve the workqueue. And it would be nice to have good debugging support.

Vincent: not a tokio fan. Trying to talk to some people working on the tokio runtime.

Miguel: Have you spoken with Alice?

Vincent: No, can you give me the contact details?

Vincent: There is some movement as to how to use a custom runtime in Rust. Working on an initiative to write directly `async fn main() {}`.

Gary: We would need some kind of runtime, right?

Bjorn: tokio-console uses protobuf as wire format. does linux already use/support it?

Boqun: maybe use `trace`?

Vincent: console is "just" like a server application.

Benno: do we want this?

pub trait Foo {
    async fn progress(&self);
}

async fn main() {
    let foo: Box<dyn Foo> = Box::new(retrieve_foo());
    foo.progress().await;// where does the future get allocated?
}

Wedson comment?

## RCU projection WIP

https://github.com/nbdd0121/linux/tree/projection

https://github.com/nbdd0121/linux/commit/6aaa6ac8390add6e89c676a8bec9de75c11adcbe