On Wed Aug 5, 2026 at 9:39 PM BST, Danilo Krummrich wrote: > On Wed Aug 5, 2026 at 1:32 PM CEST, Robin Murphy wrote: >> To be fair, that is sort of the intent in the C API as well, to be clear >> that DMA addresses must not simply be treated as physical addresses, and >> aren't necessarily address-like in general e.g. comparing two >> dma_handles is pretty meaningless, since they could have different >> values but still refer to the same underlying memory, or vice-versa. >> Adding or subtracting offsets within the bounds of the original >> allocation/mapping size is pretty much the only arithmetic that _is_ valid. > > Yes, I did suggest a dma::Range type [1] for this purpose, such that only this > kind arithmetic is possible to do. > > The dma::Range type should have a method returning its embedded raw value > which > then can be used to program registers etc. > > This patch is only an intermediate step, that clarifies that intent of the > current usage of dma_handle() (or now dma_address()), which is not to serve > as a > handle.
I suppose with I/O projections now it's rarer that people need to operate on dma address directly? What do you envison as the use case for `dma::Range`? Also, I suppose we can also represent dma address ranges as `Io` views that does not implement any accessor methods, so projection still works on them. Best, Gary > > [1] https://github.com/Rust-for-Linux/linux/issues/1248 > >> However at the Rust level, the abstraction itself can convey (and even >> enforce!) most of that, so for the sake of clarity here, particularly if >> Rust programmers are likely to have their own expectations of what >> "address" and "handle" mean, then I'm inclined to agree. > > Yeah, as mentioned in the link below, the handle that represents the > allocation > are the DMA container types (such as dma::Coherent) themselves. > >>> Link: https://lore.kernel.org/all/[email protected]/
