On Thu, Mar 13, 2025 at 03:32:14PM +0100, Simona Vetter wrote: > So I think you can still achieve that building on top of revocable and a > few more abstractions that are internally unsafe. Or are you thinking of > different runtime checks? I'm thinking on the access side of the revocable you don't have a failure path. Instead you get the access or runtime violation if the driver is buggy. This eliminates all the objectionable failure paths and costs on the performance paths of the driver. And perhaps also on the remove path you have runtime checking if "driver lifetime bound" objects have all been cleaned up. The point is to try to behave more like the standard fence pattern and get some level of checking that can make r4l comfortable without inventing new kernel lifecycle models. > Yeah maybe we're not that far really. But I'm still not clear how to do > an entirely revoke-less world. Not entirely, you end up revoking big things. Like RDMA revokes the driver ops callbacks using SRCU. It doesn't revoke individual resources or DMA maps. I have the same feeling about this micro-revoke direction, I don't know how to implement this. The DMA API is very challenging, especially the performance use of DMA API. Jason
