From: Boqun Feng <boqun.feng@gmail.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org, mcgrof@kernel.org,
russ.weight@linux.dev, ojeda@kernel.org, alex.gaynor@gmail.com,
wedsonaf@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, a.hindborg@samsung.com,
aliceryhl@google.com, airlied@gmail.com,
fujita.tomonori@gmail.com, pstanner@redhat.com,
ajanulgu@redhat.com, lyude@redhat.com,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] rust: add firmware abstractions
Date: Mon, 17 Jun 2024 16:00:22 -0700 [thread overview]
Message-ID: <ZnDABsX7RmUvnKZf@boqun-archlinux> (raw)
In-Reply-To: <ZnC9xajuhN6nSQb-@cassiopeiae>
On Tue, Jun 18, 2024 at 12:50:45AM +0200, Danilo Krummrich wrote:
[...]
> > /// A smart pointer owns the underlying data.
> > pub struct Owned<T: Ownable> {
> > ptr: NonNull<T>,
> > }
> >
> > impl<T: Ownable> Owned<T> {
> > /// # Safety
> > /// `ptr` needs to be a valid pointer, and it should be the
> > /// unique owner to the object, in other words, no one can touch
> > /// or free the underlying data.
> > pub unsafe to_owned(ptr: *mut T) -> Self {
> > // SAFETY: Per function safety requirement.
> > Self { ptr: unsafe { NonNull::new_unchecked(ptr) } }
> > }
> >
> > /// other safe constructors are available if a initializer (impl
> > /// Init) is provided
> > }
> >
> > /// A Ownable type is a type that can be put into `Owned<T>`, and
> > /// when `Owned<T>` drops, `ptr_drop` will be called.
> > pub unsafe trait Ownable {
> > /// # Safety
> > /// This could only be called in the `Owned::drop` function.
> > unsafe fn ptr_drop(ptr: *mut Self);
> > }
> >
> > impl<T: Ownable> Drop for Owned<T> {
> > fn drop(&mut self) {
> > /// SAFETY: In Owned<T>::drop.
> > unsafe {
> > <T as Ownable>::ptr_drop(self.as_mut_ptr());
> > }
> > }
> > }
> >
> > we can implement Deref and DerefMut easily on `Owned<T>`. And then we
> > could define Firmware as
> >
> > #[repr(transparent)]
> > pub struct Firmware(Opaque<bindings::firmware>);
> >
> > and
> >
> > unsafe impl Ownable for Firmware {
> > unsafe fn ptr_drop(ptr: *mut Self) {
> > // SAFETY: Per function safety, this is called in
> > // Owned::drop(), so `ptr` is a unique pointer to object,
> > // it's safe to release the firmware.
> > unsafe { bindings::release_firmware(ptr.cast()); }
> > }
> > }
> >
> > and the request_*() will return a `Result<Owned<Self>>`.
> >
> > Alice mentioned the need of this in page as well:
> >
> > https://lore.kernel.org/rust-for-linux/CAH5fLgjrt0Ohj1qBv=GrqZumBTMQ1jbsKakChmxmG2JYDJEM8w@mail.gmail.com
>
> I think in the `Page` case this is useful to create `Page` references from
> previously allocated memory.
>
> In the case of `Firmware`, I agree it makes sense to use it once we have it,
> but other than for consistency, is there any advantage?
>
To help people build future abstraction easier (and make review easier
as well). But I'm also waiting for a third use case, yes, I usually
wait for 3 cases to begin thinking about generalization ;-)
> >
> > Just bring it up while we are (maybe not? ;-)) at it. Also I would like
> > to hear whether this would work for Firmware in the longer-term ;-) But
> > yes, I'm not that worried about merging it as it is if others are all
> > OK.
>
> I think there's not too much to add here in the future, once we got an allocator
> API (I should get back to that soon), I want to add a method that copies the
> data to a new buffer allocated with a given allocator. And maybe we want to
> support a few other request_firmware_* functions in the future, but none of that
> should require the above abstraction.
>
Thank you!
> >
> > > +impl Firmware {
> > > + fn request_internal(name: &CStr, dev: &Device, func: FwFunc) -> Result<Self> {
> > > + let mut fw: *mut bindings::firmware = core::ptr::null_mut();
> > > + let pfw: *mut *mut bindings::firmware = &mut fw;
> > > +
> > > + // SAFETY: `pfw` is a valid pointer to a NULL initialized `bindings::firmware` pointer.
> > > + // `name` and `dev` are valid as by their type invariants.
> > > + let ret = unsafe { func(pfw as _, name.as_char_ptr(), dev.as_raw()) };
> > > + if ret != 0 {
> > > + return Err(Error::from_errno(ret));
> > > + }
> > > +
> > > + // SAFETY: `func` not bailing out with a non-zero error code, guarantees that `fw` is a
> > > + // valid pointer to `bindings::firmware`.
> > > + Ok(Firmware(unsafe { NonNull::new_unchecked(fw) }))
> > > + }
> > > +
> > > + /// Send a firmware request and wait for it. See also `bindings::request_firmware`.
> > > + pub fn request(name: &CStr, dev: &Device) -> Result<Self> {
> > > + Self::request_internal(name, dev, bindings::request_firmware)
> > > + }
> > > +
> > > + /// Send a request for an optional firmware module. See also
> > > + /// `bindings::firmware_request_nowarn`.
> > > + pub fn request_nowarn(name: &CStr, dev: &Device) -> Result<Self> {
> > > + Self::request_internal(name, dev, bindings::firmware_request_nowarn)
> > > + }
> > > +
> > > + fn as_raw(&self) -> *mut bindings::firmware {
> > > + self.0.as_ptr()
> > > + }
> > > +
> > > + /// Returns the size of the requested firmware in bytes.
> > > + pub fn size(&self) -> usize {
> > > + // SAFETY: Safe by the type invariant.
> > > + unsafe { (*self.as_raw()).size }
> > > + }
> > > +
> > > + /// Returns the requested firmware as `&[u8]`.
> > > + pub fn data(&self) -> &[u8] {
> > > + // SAFETY: Safe by the type invariant. Additionally, `bindings::firmware` guarantees, if
> >
> > Does this "Safe by the type invariant" also covers the following safe
> > requirement of `from_raw_parts`?
> >
> > The memory referenced by the returned slice must not be mutated for the duration of lifetime 'a, except inside an UnsafeCell.
> >
> > in that `&[u8]` has the same lifetime as `&self`, and as long as
> > `&self` exists, no function can touch the inner `data`? If so, I
> > probably want to call this out.
>
> Yes, nothing should ever modify the firmware buffer after it has been requested
> successfully. I can add this to the type invariant.
>
Oh, you have an even easier (stronger) type invariant. Yes, please add
it and use it here. Thanks!
Regards,
Boqun
> >
> > Regards,
> > Boqun
> >
> > > + // successfully requested, that `bindings::firmware::data` has a size of
> > > + // `bindings::firmware::size` bytes.
> > > + unsafe { core::slice::from_raw_parts((*self.as_raw()).data, self.size()) }
> > > + }
> > > +}
> > > +
> > > +impl Drop for Firmware {
> > > + fn drop(&mut self) {
> > > + // SAFETY: Safe by the type invariant.
> > > + unsafe { bindings::release_firmware(self.as_raw()) };
> > > + }
> > > +}
> > > +
> > > +// SAFETY: `Firmware` only holds a pointer to a C `struct firmware`, which is safe to be used from
> > > +// any thread.
> > > +unsafe impl Send for Firmware {}
> > > +
> > > +// SAFETY: `Firmware` only holds a pointer to a C `struct firmware`, references to which are safe to
> > > +// be used from any thread.
> > > +unsafe impl Sync for Firmware {}
> > > diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> > > index dd1207f1a873..7707cb013ce9 100644
> > > --- a/rust/kernel/lib.rs
> > > +++ b/rust/kernel/lib.rs
> > > @@ -30,6 +30,8 @@
> > > mod build_assert;
> > > pub mod device;
> > > pub mod error;
> > > +#[cfg(CONFIG_RUST_FW_LOADER_ABSTRACTIONS)]
> > > +pub mod firmware;
> > > pub mod init;
> > > pub mod ioctl;
> > > #[cfg(CONFIG_KUNIT)]
> > > --
> > > 2.45.1
> > >
> >
>
next prev parent reply other threads:[~2024-06-17 23:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 20:29 [PATCH v3 0/2] Rust abstractions for Device & Firmware Danilo Krummrich
2024-06-17 20:29 ` [PATCH v3 1/2] rust: add abstraction for struct device Danilo Krummrich
2024-06-18 5:31 ` Greg KH
2024-06-18 5:32 ` Greg KH
2024-06-18 8:31 ` Miguel Ojeda
2024-06-18 8:57 ` Greg KH
2024-06-17 20:29 ` [PATCH v3 2/2] rust: add firmware abstractions Danilo Krummrich
2024-06-17 22:05 ` Boqun Feng
2024-06-17 22:50 ` Danilo Krummrich
2024-06-17 23:00 ` Boqun Feng [this message]
2025-08-05 17:12 ` Andreas Hindborg
2024-06-18 19:47 ` Luis Chamberlain
2024-06-18 21:15 ` Danilo Krummrich
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=ZnDABsX7RmUvnKZf@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@samsung.com \
--cc=airlied@gmail.com \
--cc=ajanulgu@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=dakr@redhat.com \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=mcgrof@kernel.org \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=rafael@kernel.org \
--cc=russ.weight@linux.dev \
--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 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.