All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schrefl <chrisi.schrefl@gmail.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Lee Jones" <lee@kernel.org>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Danilo Krummrich" <dakr@kernel.org>
Subject: Re: [PATCH 1/3] rust: add Aliased type
Date: Thu, 23 Jan 2025 11:21:23 +0100	[thread overview]
Message-ID: <b7492912-3e58-43c4-aa0c-e6bcd4925e24@gmail.com> (raw)
In-Reply-To: <Z46Gzg_5kv-MwZNL@boqun-archlinux>



On 20.01.25 6:24 PM, Boqun Feng wrote:
> Hi Christian,
> 
> [Cc Daniel and Danilo]
> 
> Thanks for the patch!
> 
> On Sun, Jan 19, 2025 at 11:11:13PM +0100, Christian Schrefl wrote:
>> This type is useful for cases where a value might be shared with C code
>> but not interpreted by it.
>> In partiquarly this is added to for data that is shared between a Driver
>> and a MiscDevice implementation.
>>
>> Similar to Opaque but guarantees that the value is initialized and the
>> inner value is dropped when Aliased is dropped.
>>
>> This was origianally proposed for the IRQ abstractions [0], but also
>> useful for other cases where Data may be aliased, but is always valid
>> and automatic drop is desired.
>>
>> Link: https://lore.kernel.org/rust-for-linux/CAH5fLgiOASgjoYKFz6kWwzLaH07DqP2ph+3YyCDh2+gYqGpABA@mail.gmail.com [0]
>> Suggested-by: Alice Ryhl <aliceryhl@google.com>
>> Signed-off-by: Christian Schrefl <chrisi.schrefl@gmail.com>
>> ---
>>  rust/kernel/types.rs | 40 ++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 40 insertions(+)
>>
>> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
>> index 3aea6af9a0bca70ee42b4bad2fe31a99750cbf11..5640128c9a9055476a0040033946ba6caa6e7076 100644
>> --- a/rust/kernel/types.rs
>> +++ b/rust/kernel/types.rs
>> @@ -528,3 +528,43 @@ pub enum Either<L, R> {
>>  /// [`NotThreadSafe`]: type@NotThreadSafe
>>  #[allow(non_upper_case_globals)]
>>  pub const NotThreadSafe: NotThreadSafe = PhantomData;
>> +
>> +/// Stores a value that may be aliased.
>> +///
>> +/// This is similar to `Opaque<T>` but is guaranteed to contain valid data and will
>> +/// Call the Drop implementation of T when dropped.
>> +#[repr(transparent)]
>> +pub struct Aliased<T> {
> 
> As I already mentioned [1], the name `Aliased` is more reflecting the
> fact that this wrapper will avoid generating the "noalias" attribute(?)
> on the reference/pointer to the type rather than an intuitive idea about
> "why or when do I need this". Moreover, I think the argument about the
> naming of the counterpart in unstable Rust (UnsafePinned) makes sense to
> me [2]: this type alone won't prevent `&mut Aliased` getting `swap`, and
> it has to be used with `Pin`.
> 
> Therefore, I think we should use a different name, perhaps
> `(Always)Shared`, or just use `UnsafePinned`, or, as always, looking
> fowards to a better name from anybody ;-)
> 
> [1]: https://lore.kernel.org/rust-for-linux/Z407egxOy7oNLpq8@boqun-archlinux/
> [2]: https://rust-lang.github.io/rfcs/3467-unsafe-pinned.html#naming

I don't particularly care about the name, I mostly used aliased, because that's
the name that Alice originally used.

`(Always)Shared` seems confusing to me.

I guess we can use `UnsafePinned`, but most people won't know what that means,
also I'm not sure if it's a good Idea to use the same name as a (future) 
language type.

If there is a consensus on a good name I'll use that for the next version.

> 
> Regards,
> Boqun
> 
>> +    value: UnsafeCell<T>,
>> +    _pin: PhantomPinned,
>> +}
>> +
>> +impl<T> Aliased<T> {
>> +    /// Creates a new `Aliased` value.
>> +    pub const fn new(value: T) -> Self {
>> +        Self {
>> +            value: UnsafeCell::new(value),
>> +            _pin: PhantomPinned,
>> +        }
>> +    }
>> +    /// Create an `Aliased` pin-initializer from the given pin-initializer.
>> +    pub fn try_pin_init<E>(value: impl PinInit<T, E>) -> impl PinInit<Self, E> {
>> +        // SAFETY:
>> +        // In case of an error in value the error is returned, otherwise the slot is fully initialized,
>> +        // since value is initialized and _pin is a Zero sized type.
>> +        // The pin invariants of value are upheld, since no moving occurs.
>> +        unsafe { init::pin_init_from_closure(move |slot| value.__pinned_init(Self::raw_get(slot))) }
>> +    }
>> +    /// Returns a raw pointer to the opaque data.
>> +    pub const fn get(&self) -> *mut T {
>> +        UnsafeCell::get(&self.value).cast::<T>()
>> +    }
>> +
>> +    /// Gets the value behind `this`.
>> +    ///
>> +    /// This function is useful to get access to the value without creating intermediate
>> +    /// references.
>> +    pub const fn raw_get(this: *const Self) -> *mut T {
>> +        UnsafeCell::raw_get(this.cast::<UnsafeCell<MaybeUninit<T>>>()).cast::<T>()
>> +    }
>> +}
>>
>> -- 
>> 2.48.1
>>


  reply	other threads:[~2025-01-23 10:21 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-19 22:11 [PATCH 0/3] rust: miscdevice: Add additional data to MiscDeviceRegistration Christian Schrefl
2025-01-19 22:11 ` [PATCH 1/3] rust: add Aliased type Christian Schrefl
2025-01-19 23:04   ` Miguel Ojeda
2025-01-20  0:27     ` Christian Schrefl
2025-01-20 17:24   ` Boqun Feng
2025-01-23 10:21     ` Christian Schrefl [this message]
2025-01-23 17:56       ` Boqun Feng
2025-01-23 18:04         ` Christian Schrefl
2025-01-23 18:25           ` Boqun Feng
2025-01-23 20:18             ` Christian Schrefl
2025-01-23 20:24               ` Boqun Feng
2025-01-23 20:27                 ` Christian Schrefl
2025-01-19 22:11 ` [PATCH 2/3] rust: miscdevice: Add additional data to MiscDeviceRegistration Christian Schrefl
2025-01-20  0:27   ` Christian Schrefl
2025-01-21 10:53   ` kernel test robot
2025-01-22  9:28   ` Greg Kroah-Hartman
2025-01-22 10:11     ` Alice Ryhl
2025-01-22 12:40       ` Greg Kroah-Hartman
2025-01-22 13:06         ` Alice Ryhl
2025-01-23 10:02           ` Christian Schrefl
2025-01-23 15:52     ` Christian Schrefl
2025-01-23 16:00       ` Greg Kroah-Hartman
2025-01-23 16:04         ` Christian Schrefl
2025-01-23 23:26   ` Christian Schrefl
2025-01-27 10:27     ` Alice Ryhl
2025-01-27 13:27       ` Christian Schrefl
2025-01-27 13:33         ` Alice Ryhl
2025-01-27 13:35           ` Christian Schrefl
2025-01-27 13:42           ` Miguel Ojeda
2025-01-19 22:11 ` [PATCH 3/3] rust: miscdevice: adjust the rust_misc_device sample to use RegistrationData Christian Schrefl
2025-01-21 15:40   ` Alice Ryhl
2025-01-23 17:57     ` Christian Schrefl
2025-01-24  7:29       ` Alice Ryhl
2025-01-24  8:06         ` Greg Kroah-Hartman
2025-01-24  9:42           ` Alice Ryhl
2025-01-24 10:34             ` Greg Kroah-Hartman
2025-01-24 10:39               ` Alice Ryhl
2025-01-24 11:22                 ` Greg Kroah-Hartman
2025-01-24 11:37                   ` Alice Ryhl
2025-01-24 11:42                     ` Christian Schrefl
2025-01-20  5:46 ` [PATCH 0/3] rust: miscdevice: Add additional data to MiscDeviceRegistration Greg Kroah-Hartman
2025-01-21 10:29   ` Christian Schrefl
2025-01-22  9:22     ` Greg Kroah-Hartman

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=b7492912-3e58-43c4-aa0c-e6bcd4925e24@gmail.com \
    --to=chrisi.schrefl@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=arnd@arndb.de \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.