On Thu, Sep 18, 2025 at 02:30:59PM +0200, Philipp Stanner wrote: [...] > --- > So. ¡Hola! > > This is a highly WIP RFC. It's obviously at many places not yet > conforming very well to Rust's standards. > > Nevertheless, it has progressed enough that I want to request comments > from the community. > > There are a number of TODOs in the code to which I need input. > > Notably, it seems (half-)illegal to use a shared static reference to an > Atomic, which I currently use for the dma_fence unit test / docstring
The `CHECKER` static you mean? If so, it should be a `static CHECKER` instead of `static mut CHECKER`, also for future versions please use LKMM (Linux Kernel Memory Model) atomics [1] instead of Rust native atomics (you probably need to define `CHECKER` as `Atomic<i32>` because AtomicBool is not supported by LKMM and potentially sub-optimial in some cases). > test. I'm willing to rework that if someone suggests how. > (Still, shouldn't changing a global Atomic always be legal? It can race, > of course. But that's kind of the point of an atomic) > > What I want comments on the most is the design of the callbacks. I think > it's a great opportunity to provide Rust drivers with rust-only > callbacks, so that they don't have to bother about the C functions. > > dma_fence wise, only the most basic callbacks currently get implemented. > For Nova, AFAICS, we don't need much more than signalling fences and > registering callbacks. > > > Another, solvable, issue I'm having is designing the > dma_fence_begin_signallin() abstractions. There are TODOs about that in > the code. That should ideally be robust and not racy. So we might want > some sort of synchronized (locked?) way for using that abstraction. > > > Regarding the manually created spinlock of mine: I so far never need > that spinlock anywhere in Rust and wasn't sure what's then the best way > to pass a "raw" spinlock to C. > You can use `SpinLock<()>` for this purpose, no need to add new bindings. [1]: https://lore.kernel.org/rust-for-linux/20250905044141.77868-1-boqun.f...@gmail.com/ Regards, Boqun > > So much from my side. Hope to hear from you. > > (I've compiled and tested this with the unit test on the current -rc3) > > Philipp > --- [...]
