Re: [PATCH 2/2] gpu: nova-core: falcon: use I/O projection to check transfer bounds

On Sat Jul 25, 2026 at 7:27 AM JST, Danilo Krummrich wrote:
> On Fri Jul 24, 2026 at 8:10 PM CEST, John Hubbard wrote:
>> Sort of "conceptually pre-existing" problem, but "handle" doesn't
>> quite work as a name, because handles are supposed to be opaque
>> items that one just uses to find and refer to things.
>
> This is inherited from the C API where from its perspective the returned base
> DMA address of the allocation actually serves as a handle.
>
> In Rust the actual handle is represented by different types with different
> invariants and hence capabilties.
>
> (For instance, dma::CoherentBox does not expose the DMA address at all, and
> hence provides access to its contents through a direct mutable reference,
> whereas dma::CoherentHandle only provides access to the DMA address and does not
> have a CPU virtual mapping; dma::Coherent provides access to both.)
>
> Both dma::Coherent and dma::CoherentHandle have a dma_handle() method which
> provides access to the DMA address; this naming was taken over from the C API.
>
> Given that the base DMA address serving as a handle from the perspective of the
> C API is just an implementation detail, we should probably just rename this
> method to dma_address().

I was also thinking about using `dma_address`, so let's do that!

I guess the pieces required to support a proper DMA range type are also
starting to fall together.