On Fri Jan 23, 2026 at 3:09 AM GMT, John Hubbard wrote: > On 1/13/26 6:23 PM, John Hubbard wrote: >> On 1/13/26 5:28 AM, Gary Guo wrote: >>> On Wed Dec 3, 2025 at 5:58 AM GMT, John Hubbard wrote: >> ... >>>> +pub(crate) struct FbRange(Range<u64>); >>> >>> How useful do you think this is in general? Would it make sense to have a >>> dedicated PhysAddrRange type in kernel crate that provides this feature? > > I still like this general direction. > >> >> Pretty useful. Yes that sounds like a good move. And I see from Miguel's >> reply that Gent Binaku (+CC) has a patch that proposes adding a >> PhysAddrRange. I'll go review it in detail. > > (correction: PhysAddr, actually. No PhysAddrRange just yet.) > > OK, I looked into this in some detail. Based on my experience with this > area in HMM (a linux-mm feature that deals with both CPU and GPU memory > addresses), I'm pretty solidly convinced that PhysAddr is meant for CPU > physical addresses. > > FbRange, on the other hand, is intended for VRAM (a GPU's dedicated > memory), which is often in a separate address space. So these should not > be the same Rust type. We'll likely want separate types for CPU, GPU > (or "device") memory, and even DMA memory. > > In order to avoid seriously derailing the review of this Blackwell > series, I'm going to continue that thought, in more detail, as part of > my review of the PhysAddr patch [1]. > > Meanwhile, I propose letting this aspect of this series remain as-is.
Fair. Although an always u64 type could still be useful in general, just like drm_buddy/gpu_buddy. I would imagine some accelerator wanting things similar too. Of course we can always have this start as Nova-specific and move out as needed. Best, Gary > > > [1] > https://lore.kernel.org/rust-for-linux/[email protected]/ > > thanks,
