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. [1] https://lore.kernel.org/rust-for-linux/[email protected]/ thanks, -- John Hubbard
