[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zp_DIEOj0PtNywmA@casper.infradead.org>
Date: Tue, 23 Jul 2024 15:50:08 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Boqun Feng <boqun.feng@...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@...sung.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] rust: mm: add abstractions for mm_struct and
vm_area_struct
On Tue, Jul 23, 2024 at 02:32:03PM +0000, Alice Ryhl wrote:
> +// SAFETY: It is safe to call `mmdrop` on another thread than where `mmgrab` was called.
If I were reading the documentation, I might want to know if it's safe
to call in interrupt context (either soft or hard). ie can mmdrop
sleep (if it turns out to be the last owner of the mm).
> +/// A wrapper for the kernel's `struct vm_area_struct`.
> +///
> +/// It represents an area of virtual memory.
> +#[repr(transparent)]
> +pub struct Area {
> + vma: Opaque<bindings::vm_area_struct>,
> +}
That seems like a very generic name! MMArea? VMA? Certainly when I'm
talking to people, I say VMA. struct vm_area_struct is a terrible name
and I'd be happy to change it if we could stomach that churn. If I were
naming it today, I'd want to call it struct mm_area.
Powered by blists - more mailing lists