Hi Danilo, > On 10 Aug 2026, at 19:19, Danilo Krummrich <[email protected]> wrote: > > On Mon Aug 10, 2026 at 9:44 PM CEST, Daniel Almeida wrote: >> As I said on the cover letter, I'd rather keep the 'bound design for now, >> leaving the door open to the Devres approach that we will eventually need in >> the future. > > What exacly do you mean by this?
We have a lot of places in our downstream driver where it's not really clear whether an &IoMem<'bound> and etc will be available. E.g.: places like the submit path or the async vm_bind path, both invoked from the JobQueue, which runs on its own workqueue in our downstream implementation. i.e. when the JobQueue calls the driver's "submit to hardware" handler, Tyr needs an IoMem to perform the mapping in the vm_bind case, or to write the doorbell register in the submit case. Also places using delayed work, which is still restricted to 'static workqueues IIUC. That's what I meant by "Devres we will eventually need in the future". Perhaps there is a plan to relax the 'static requirement like what happened recently to the IRQ code? Because otherwise my suggestion would be try_access(). — Daniel
