On Thu Aug 28, 2025 at 9:58 PM CEST, Danilo Krummrich wrote: > On Thu Aug 28, 2025 at 9:36 PM CEST, Miguel Ojeda wrote: >> On Thu, Aug 28, 2025 at 9:31 PM Miguel Ojeda >> <[email protected]> wrote: >>> >>> and a `DmaAddress` >>> newtype, not just a typedef, could perhaps be nice anyway? >> >> The one from your linked patch is not a newtype though, so I guess >> there is a reason for that. > > No specific reason, I didn't see a lot of value in a newtype in the first > place, depending on you answer in the other thread, may we just found some > value. :)
To expand a bit, the typdef is also for simplicity. Eventually, drivers will do some arithmetic on the DMA address, etc. So, if we have a new type, we'd probably want to provide methods for doing the most common arithmetic operations, because we don't want to convert to/from the corresponding primitive type all the time. At the same time we could take this further and also provide a DmaRange type, which also considers the size for those operations. DmaRange is actually something that I had in mind to implement subsequently, because I'm not too happy with CoherentAllocation::dma_handle_with_offset(), it's just too specific and insufficient. Given that, I thought there's not that much value in making DmaAddress a new type. (Mybe saying "no specific reason" was a slight understatement. :) So, if the idea was to have from/to helpers, we can also do them on DmaRange. However, given that also the above only helps in a limited way for the cases discussed in the other thread, I feel like the best option might still be to depend on 64-bit for Nova.
