On Wed, 21 Jan 2026 19:25:27 -0800 Bobby Eshleman wrote: > > > That is correct, neither is true. If the two sockets share a binding the > > > kernel doesn't care which socket received the token or which one > > > returned it. No token <> socket association. There is no > > > queued-but-not-read race either. If any tokens are not returned, as long > > > as all of the binding references are eventually released and all sockets > > > that used the binding are closed, then all references will be accounted > > > for and everything cleaned up. > > > > Naming is hard, but I wonder whether the whole feature wouldn't be > > better referred to as something to do with global token accounting > > / management? AUTORELEASE makes sense but seems like focusing on one > > particular side effect. > > Good point. The only real use case for autorelease=on is for backwards > compatibility... so I thought maybe DEVMEM_A_DMABUF_COMPAT_TOKEN > or DEVMEM_A_DMABUF_COMPAT_DONTNEED would be clearer?
Hm. Maybe let's return to naming once we have consensus on the uAPI. Does everyone think that pushing this via TCP socket opts still makes sense, even tho in practice the TCP socket is just how we find the binding?
