| Message ID | 20250202-rust-page-v1-4-e3170d7fe55e@asahilina.net (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | rust: page: Support borrowing `struct page` and physaddr conversion | expand |
On Sun, Feb 2, 2025 at 2:06 PM Asahi Lina <lina@asahilina.net> wrote: > > Encapsulates the core physical/DMA address types, so they can be used by > Rust abstractions. > > Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
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@asahilina.net> > --- > 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? Regards, Boqun > pub mod alloc; > #[cfg(CONFIG_BLOCK)] > pub mod block; > > -- > 2.47.1 >
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@asahilina.net> >> --- >> 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). 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. > > Regards, > Boqun > >> pub mod alloc; >> #[cfg(CONFIG_BLOCK)] >> pub mod block; >> >> -- >> 2.47.1 >> > ~~ Lina
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@asahilina.net> > >> --- > >> 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 >
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; + +/// 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; pub mod alloc; #[cfg(CONFIG_BLOCK)] pub mod block;
Encapsulates the core physical/DMA address types, so they can be used by Rust abstractions. Signed-off-by: Asahi Lina <lina@asahilina.net> --- rust/kernel/addr.rs | 15 +++++++++++++++ rust/kernel/lib.rs | 1 + 2 files changed, 16 insertions(+)