[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f098064-d2d5-4a02-8306-0a3d31557bab@asahilina.net>
Date: Tue, 4 Feb 2025 20:50:17 +0900
From: Asahi Lina <lina@...hilina.net>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Jann Horn <jannh@...gle.com>,
Matthew Wilcox <willy@...radead.org>, Paolo Bonzini <pbonzini@...hat.com>,
Danilo Krummrich <dakr@...nel.org>, Wedson Almeida Filho
<wedsonaf@...il.com>, Valentin Obst <kernel@...entinobst.de>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
airlied@...hat.com, Abdiel Janulgue <abdiel.janulgue@...il.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
asahi@...ts.linux.dev
Subject: Re: [PATCH 4/6] rust: addr: Add a module to declare core address
types
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@...hilina.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
Powered by blists - more mailing lists