Re: [PATCH 4/6] rust: addr: Add a module to declare core address types

From: Boqun Feng
Date: Tue Feb 04 2025 - 09:50:44 EST


On Tue, Feb 04, 2025 at 08:50:17PM +0900, Asahi Lina wrote:
>
>
> On 2/4/25 12:04 AM, Boqun Feng wrote:
> > On Sun, Feb 02, 2025 at 10:05:46PM +0900, Asahi Lina wrote:
> >> Encapsulates the core physical/DMA address types, so they can be used by
> >> Rust abstractions.
> >>
> >> Signed-off-by: Asahi Lina <lina@xxxxxxxxxxxxx>
> >> ---
> >> rust/kernel/addr.rs | 15 +++++++++++++++
> >> rust/kernel/lib.rs | 1 +
> >> 2 files changed, 16 insertions(+)
> >>
> >> diff --git a/rust/kernel/addr.rs b/rust/kernel/addr.rs
> >> new file mode 100644
> >> index 0000000000000000000000000000000000000000..06aff10a0332355597060c5518d7fd6e114cf630
> >> --- /dev/null
> >> +++ b/rust/kernel/addr.rs
> >> @@ -0,0 +1,15 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +
> >> +//! Kernel core address types.
> >> +
> >> +use bindings;
> >> +use core::ffi;
> >
> > I think we should use crate::ffi here. See:
> >
> > d072acda4862 "rust: use custom FFI integer types"
> >
> >> +
> >> +/// A physical memory address (which may be wider than the CPU pointer size)
> >> +pub type PhysicalAddr = bindings::phys_addr_t;
> >> +/// A DMA memory address (which may be narrower than `PhysicalAddr` on some systems)
> >> +pub type DmaAddr = bindings::dma_addr_t;
> >> +/// A physical resource size, typically the same width as `PhysicalAddr`
> >> +pub type ResourceSize = bindings::resource_size_t;
> >> +/// A raw page frame number, not to be confused with the C `pfn_t` which also encodes flags.
> >> +pub type Pfn = ffi::c_ulong;
> >> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> >> index e1065a7551a39e68d6379031d80d4be336e652a3..eb1a80ba8ff83ab2d1b3b1d11fed4fb704c7a4f5 100644
> >> --- a/rust/kernel/lib.rs
> >> +++ b/rust/kernel/lib.rs
> >> @@ -29,6 +29,7 @@
> >>
> >> pub use ffi;
> >>
> >> +pub mod addr;
> >
> > I want to share my worry on this `pub mod` list in kernel/lib.rs may get
> > too long ;-)
> >
> > I was about to suggest putting `addr` and `page` into `mm` after Alice's
> > patchset merged, however, seems that `mm` mod only cover userspace
> > memory management (which is not my impression of what "mm" in kernel
> > development), thoughts? Alice, do you think we should extend `mm` mod to
> > contain all memory management mods?
>
> I think in kernel-speak "mm" is usually userspace memory management and
> kernel page allocation and memory management, but doesn't include device
> stuff (I/O ranges, DMA, etc.) or the low-level concepts of memory in an
> architecture. The types I declare here are more relevant to device/arch
> code, so I don't think they really belong under "mm", it's more general
> (mm deals with them and so do other parts of the kernel code).
>

Make sense.

> On the other hand, I think page.rs itself would fit under mm, since it
> deals with the kernel mm's idea of pages and their allocation.
>

Agreed. Probably some follow-up work after Alice's mm work merged.

Regards,
Boqun

> >
> > Regards,
> > Boqun
> >
> >> pub mod alloc;
> >> #[cfg(CONFIG_BLOCK)]
> >> pub mod block;
> >>
> >> --
> >> 2.47.1
> >>
> >
>
> ~~ Lina
>