Re: [PATCH v2 2/3] rust: dma: rename dma_handle to dma_address

[Gary Guo]

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/DK75LUA4NLGI.3P29AIZQE20V2@xxxxxxxxxx/