rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
To: Benno Lossin <benno.lossin@proton.me>,
	Miguel Ojeda <ojeda@kernel.org>,
	Wedson Almeida Filho <wedsonaf@gmail.com>,
	Alex Gaynor <alex.gaynor@gmail.com>
Cc: "Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Andreas Hindborg" <nmi@metaspace.dk>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Asahi Lina" <lina@asahilina.net>
Subject: Re: [PATCH v2 11/12] rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`
Date: Thu, 20 Jul 2023 21:23:20 -0300	[thread overview]
Message-ID: <0b818707-4762-c12d-8624-7d3c4f6841da@gmail.com> (raw)
In-Reply-To: <20230719141918.543938-12-benno.lossin@proton.me>

On 7/19/23 11:21, Benno Lossin wrote:
> The `{pin_}chain` functions extend an initializer: it not only
> initializes the value, but also executes a closure taking a reference to
> the initialized value. This allows to do something with a value directly
> after initialization.
> 
> Suggested-by: Asahi Lina <lina@asahilina.net>
> Signed-off-by: Benno Lossin <benno.lossin@proton.me>
> ---
>   rust/kernel/init.rs            | 138 +++++++++++++++++++++++++++++++++
>   rust/kernel/init/__internal.rs |   2 +-
>   2 files changed, 139 insertions(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs
> index 3c7cd36a424b..3b0df839f64c 100644
> --- a/rust/kernel/init.rs
> +++ b/rust/kernel/init.rs
> @@ -773,6 +773,77 @@ pub unsafe trait PinInit<T: ?Sized, E = Infallible>: Sized {
>       ///   deallocate.
>       /// - `slot` will not move until it is dropped, i.e. it will be pinned.
>       unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E>;
> +
> +    /// First initializes the value using `self` then calls the function `f` with the initialized
> +    /// value.
> +    ///
> +    /// # Examples
> +    ///
> +    /// ```rust
> +    /// # #![allow(clippy::disallowed_names)]
> +    /// use kernel::{types::Opaque, init::pin_init_from_closure};
> +    /// #[repr(C)]
> +    /// struct RawFoo([u8; 16]);
> +    /// extern {
> +    ///     fn init_foo(_: *mut RawFoo);
> +    /// }
> +    ///
> +    /// #[pin_data]
> +    /// struct Foo {
> +    ///     #[pin]
> +    ///     raw: Opaque<RawFoo>,
> +    /// }
> +    ///
> +    /// impl Foo {
> +    ///     fn setup(self: Pin<&mut Self>) {
> +    ///         pr_info!("Setting up foo");
> +    ///     }
> +    /// }
> +    ///
> +    /// let foo = pin_init!(Foo {
> +    ///     raw <- unsafe {
> +    ///         Opaque::ffi_init(|s| {
> +    ///             init_foo(s);
> +    ///         })
> +    ///     },
> +    /// }).pin_chain(|foo| {
> +    ///     foo.setup();
> +    ///     Ok(())
> +    /// });
> +    /// ```
> +    fn pin_chain<F>(self, f: F) -> ChainPinInit<Self, F, T, E>
> +    where
> +        F: FnOnce(Pin<&mut T>) -> Result<(), E>,
> +    {
> +        ChainPinInit(self, f, PhantomData)
> +    }
> +}
> +
> +/// An initializer returned by [`PinInit::pin_chain`].
> +pub struct ChainPinInit<I, F, T: ?Sized, E>(I, F, __internal::Invariant<(E, Box<T>)>);
> +
> +// SAFETY: the `__pinned_init` function is implemented such that it
> +// - returns `Ok(())` on successful initialization,
> +// - returns `Err(err)` on error and in this case `slot` will be dropped.
> +// - considers `slot` pinned.
> +unsafe impl<T: ?Sized, E, I, F> PinInit<T, E> for ChainPinInit<I, F, T, E>
> +where
> +    I: PinInit<T, E>,
> +    F: FnOnce(Pin<&mut T>) -> Result<(), E>,
> +{
> +    unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E> {
> +        // SAFETY: all requirements fulfilled since this function is `__pinned_init`.
> +        unsafe { self.0.__pinned_init(slot)? };
> +        // SAFETY: The above call initialized `slot` and we still have unique access.
> +        let val = unsafe { &mut *slot };
> +        // SAFETY: `slot` is considered pinned
> +        let val = unsafe { Pin::new_unchecked(val) };
> +        (self.1)(val).map_err(|e| {
> +            // SAFETY: `slot` was initialized above.
> +            unsafe { core::ptr::drop_in_place(slot) };
> +            e

I might stumble upon an error like EAGAIN if I call `pin_chain` but that
means `slot` will be dropped. So my recommendation is to either not drop
the value or detail in `pin_chain`'s doc comment that the closure will
drop on error.

> +        })
> +    }
>   }
>   
>   /// An initializer for `T`.
> @@ -814,6 +885,73 @@ pub unsafe trait Init<T: ?Sized, E = Infallible>: PinInit<T, E> {
>       /// - the caller does not touch `slot` when `Err` is returned, they are only permitted to
>       ///   deallocate.
>       unsafe fn __init(self, slot: *mut T) -> Result<(), E>;
> +
> +    /// First initializes the value using `self` then calls the function `f` with the initialized
> +    /// value.
> +    ///
> +    /// # Examples
> +    ///
> +    /// ```rust
> +    /// # #![allow(clippy::disallowed_names)]
> +    /// use kernel::{types::Opaque, init::{self, init_from_closure}};
> +    /// struct Foo {
> +    ///     buf: [u8; 1_000_000],
> +    /// }
> +    ///
> +    /// impl Foo {
> +    ///     fn setup(&mut self) {
> +    ///         pr_info!("Setting up foo");
> +    ///     }
> +    /// }
> +    ///
> +    /// let foo = init!(Foo {
> +    ///     buf <- init::zeroed()
> +    /// }).chain(|foo| {
> +    ///     foo.setup();
> +    ///     Ok(())
> +    /// });
> +    /// ```
> +    fn chain<F>(self, f: F) -> ChainInit<Self, F, T, E>
> +    where
> +        F: FnOnce(&mut T) -> Result<(), E>,
> +    {
> +        ChainInit(self, f, PhantomData)
> +    }
> +}
> +
> +/// An initializer returned by [`Init::chain`].
> +pub struct ChainInit<I, F, T: ?Sized, E>(I, F, __internal::Invariant<(E, Box<T>)>);
> +
> +// SAFETY: the `__init` function is implemented such that it
> +// - returns `Ok(())` on successful initialization,
> +// - returns `Err(err)` on error and in this case `slot` will be dropped.
> +unsafe impl<T: ?Sized, E, I, F> Init<T, E> for ChainInit<I, F, T, E>
> +where
> +    I: Init<T, E>,
> +    F: FnOnce(&mut T) -> Result<(), E>,
> +{
> +    unsafe fn __init(self, slot: *mut T) -> Result<(), E> {
> +        // SAFETY: all requirements fulfilled since this function is `__init`.
> +        unsafe { self.0.__pinned_init(slot)? };
> +        // SAFETY: The above call initialized `slot` and we still have unique access.
> +        (self.1)(unsafe { &mut *slot }).map_err(|e| {
> +            // SAFETY: `slot` was initialized above.
> +            unsafe { core::ptr::drop_in_place(slot) };
> +            e
> +        })
> +    }
> +}
> +
> [...]

Same as above.

  reply	other threads:[~2023-07-21  0:26 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19 14:20 [PATCH v2 00/12] Quality of life improvements for pin-init Benno Lossin
2023-07-19 14:20 ` [PATCH v2 01/12] rust: init: consolidate init macros Benno Lossin
2023-07-19 18:37   ` Martin Rodriguez Reboredo
2023-07-20 13:09   ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 02/12] rust: add derive macro for `Zeroable` Benno Lossin
2023-07-19 18:42   ` Martin Rodriguez Reboredo
2023-07-20 13:13   ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 03/12] rust: init: make guards in the init macros hygienic Benno Lossin
2023-07-19 19:04   ` Martin Rodriguez Reboredo
2023-07-20 13:16   ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 04/12] rust: init: wrap type checking struct initializers in a closure Benno Lossin
2023-07-19 19:05   ` Martin Rodriguez Reboredo
2023-07-20 13:17   ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 05/12] rust: init: make initializer values inaccessible after initializing Benno Lossin
2023-07-19 19:07   ` Martin Rodriguez Reboredo
2023-07-20 13:19   ` Alice Ryhl
2023-07-19 14:20 ` [PATCH v2 06/12] rust: init: add `..Zeroable::zeroed()` syntax for zeroing all missing fields Benno Lossin
2023-07-20 13:25   ` Alice Ryhl
2023-07-20 13:51   ` Martin Rodriguez Reboredo
2023-07-19 14:20 ` [PATCH v2 07/12] rust: init: Add functions to create array initializers Benno Lossin
2023-07-20 13:28   ` Alice Ryhl
2023-07-20 13:59   ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 08/12] rust: init: add support for arbitrary paths in init macros Benno Lossin
2023-07-20 13:30   ` Alice Ryhl
2023-07-20 14:02   ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 09/12] rust: init: implement Zeroable for Opaque<T> Benno Lossin
2023-07-20 13:34   ` Alice Ryhl
2023-07-24 14:16     ` Benno Lossin
2023-07-25 11:57       ` Alice Ryhl
2023-07-29  4:11         ` Benno Lossin
2023-07-29  8:14           ` Alice Ryhl
2023-07-20 14:03   ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 10/12] rust: init: make `PinInit<T, E>` a supertrait of `Init<T, E>` Benno Lossin
2023-07-20 13:36   ` Alice Ryhl
2023-07-20 14:07   ` Martin Rodriguez Reboredo
2023-07-19 14:21 ` [PATCH v2 11/12] rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>` Benno Lossin
2023-07-21  0:23   ` Martin Rodriguez Reboredo [this message]
2023-07-24 14:08     ` Benno Lossin
2023-07-24 16:07       ` Martin Rodriguez Reboredo
2023-07-24 21:55         ` Benno Lossin
2023-07-19 14:21 ` [PATCH v2 12/12] rust: init: update expanded macro explanation Benno Lossin
2023-07-21  0:24   ` Martin Rodriguez Reboredo
2023-07-19 15:23 ` [PATCH v2 00/12] Quality of life improvements for pin-init Benno Lossin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b818707-4762-c12d-8624-7d3c4f6841da@gmail.com \
    --to=yakoyoku@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=lina@asahilina.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nmi@metaspace.dk \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).