# Asahi Lina Meeting * PR tracking a few dependencies: https://github.com/Rust-for-Linux/linux/pull/952 * Lina: next step plan ## Dependencies ### DRM * [ ] device * [x] Opaque * [x] ForeignOwned ### Asahi Driver - [ ] IoMem - [ ] device - [ ] platform - [ ] io_buffer - [ ] user_ptr - [ ] sync::smutex - [ ] sync::Mutex - [ ] sync::CondVar ## What makes Daniel happy - [ ] ww_mutex support - [ ] lockdep support / mutex init ## Questions from Lina - [ ] `ver` thing ok? - [ ] placement new support - Gary: we may solve this with pin-init branch: https://github.com/AsahiLinux/linux/tree/gpu/rust-for-later * License about `Arc::downcast()` `Unpin`: safe to move after pinned `!Unpin`: unsafe to move after pinned ## Lina action items - [x] XArray v2 & add Pin<> & add comment explaining why we don't need the trylock stuff in drop - [x] ioctl v2 (static assert) - [ ] time v2 - [x] error v2 + cleanup - [x] macro v2 (drop concat_idents) - [x] uapi crate - [x] assume_init patch: merge in comment - [x] arc: fix licensing thing - [x] minor v3 bumps - [ ] website page For later - [ ] DMA address mess (open issue) ## Gary action items - [x] Device - [ ] Review sync - [x] `paste!` Additionally, we may want a different way to wrap devices ```rust= #[repr(transparent)] pub struct Device(UnsafeCell(bindings::drm_device)); pub struct DeviceRef(...); // or ARef<Device> ``` ## Feedbacks from Daniel https://lore.kernel.org/rust-for-linux/ZC2rbZzho2YMi5cq@phenom.ffwll.local/ ### Refcounting vs borrow #### Refcounted types: * drm_driver * drm_device (ideally driver should not have refcounts on devices) #### Not refcounted: * [ ] hwdevice: * "the actual hardware resource", whose lifetime is "limited by hotunplug or more precisiely, how long your driver is bound to the struct device." * [ ] Boqun: Does it mean only driver callbacks can access this part? * "usually the the link from hwdevice to drm_device is done with a refcounted drm_device stored with dev_set_drvdata." * [ ] Boqun: This looks like a function `fn(&HwDevice) -> ARef<drm_device>` is needed? Although I don't know the usage of this function ;-) * "For rust this means that we really should try to tie all the hw related things into devm or equivalent, and make both sure it's automatically cleaned up at that point, but also no later (because if you clean up hw stuff after ->remove you have a driver bug)." Boqun: My understanding is this `hwdevice` abstraction is: Not refcounted and the lifetime is maintained by the driver (probably via `devm`-like mechanism), and need to make reset/cleanup happen before when the driver remove the device. * [ ] `drmm` counterpart Boqun: IIUC, there are certain types (e.g. like `drm_buf`) which belong to one `drm_device` and need to be freed when the `drm_device` is dropped. And I think Daniel also prefers these don't have their own refcounts, right? ### Safety around `drm_device::dev` ```clike= struct drm_device { ... struct device *dev; ... } ``` * Accessing `->dev` needs protection: "bus/driver core callbacks or drm_dev_enter/exit" * Do we need to support both checking statically? If so we probably need a trait and different Device types depending on the context (bus/driver callbacks -> direct access, otherwise drm_dev_enter/exit needed). * "Furthermore we need to ensure that that drm_dev_unplug really is the first thing done in ->remove" Notes: (for using lockdep for Arc tracking) Daniel: The tricky part is choosing the correct lockdep class for Arc Gary: If the performance doesn't matter (Boqun: no it doesn't), we can use the ... Gary: We can dynamically allocate lockdep class Boqun: But we need to free lockdep classes Lina: What if we inline the function, and use asm to make sure lockdep classes are created in special section? Gary: We still have to deduplicate Daniel: What lockdep misses is might_sleep(), maybe we need Arc and `ArcAtomic` (Arc whose final drops cannot be sleepable) https://rustc-dev-guide.rust-lang.org/backend/implicit-caller-location.html https://rust-for-linux.com/klint.html Lina: Will experiment the whole idea for `Arc` with lockdep. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=ba29740f3002744c18d65bcef92df5d5 Boqun: Will talk with Wedson about the devices/drivers things for a plan.