From: Philipp Stanner <pstanner@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>,
Wedson Almeida Filho <wedsonaf@gmail.com>
Cc: Danilo Krummrich <dakr@redhat.com>,
rafael@kernel.org, ojeda@kernel.org, alex.gaynor@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@samsung.com, aliceryhl@google.com,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, rust-for-linux@vger.kernel.org,
x86@kernel.org, lyude@redhat.com, ajanulgu@redhat.com,
airlied@redhat.com, Asahi Lina <lina@asahilina.net>
Subject: Re: [PATCH 3/8] rust: device: Add a stub abstraction for devices
Date: Wed, 27 Mar 2024 10:05:51 +0100 [thread overview]
Message-ID: <dc21d9dc9be739122e60caefa0f75ac29bd2a3c7.camel@redhat.com> (raw)
In-Reply-To: <2024032703-mobile-perch-0a55@gregkh>
On Wed, 2024-03-27 at 06:22 +0100, Greg KH wrote:
> On Tue, Mar 26, 2024 at 10:38:49PM -0300, Wedson Almeida Filho wrote:
> > On Mon, 25 Mar 2024 at 15:17, Greg KH <gregkh@linuxfoundation.org>
> > wrote:
> > >
> > > On Mon, Mar 25, 2024 at 06:49:07PM +0100, Danilo Krummrich wrote:
> > > > From: Wedson Almeida Filho <wedsonaf@gmail.com>
> > > >
> > > > Add a Device type which represents an owned reference to a
> > > > generic
> > > > struct device. This minimal implementation just handles
> > > > reference
> > > > counting and allows the user to get the device name.
> > > >
> > > > Also, implement the rust_helper_dev_get_drvdata helper.
> > > >
> > > > Co-developed-by: Miguel Ojeda <ojeda@kernel.org>
> > > > Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> > > > Co-developed-by: Asahi Lina <lina@asahilina.net>
> > > > Signed-off-by: Asahi Lina <lina@asahilina.net>
> > > > Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
> > > > Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> > > > ---
> > > > rust/helpers.c | 13 ++++++++
> > > > rust/kernel/device.rs | 76
> > > > ++++++++++++++++++++++++++++++++++++++++++-
> > > > 2 files changed, 88 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/rust/helpers.c b/rust/helpers.c
> > > > index 70e59efd92bc..1e40661a33d1 100644
> > > > --- a/rust/helpers.c
> > > > +++ b/rust/helpers.c
> > > > @@ -23,6 +23,7 @@
> > > > #include <kunit/test-bug.h>
> > > > #include <linux/bug.h>
> > > > #include <linux/build_bug.h>
> > > > +#include <linux/device.h>
> > > > #include <linux/err.h>
> > > > #include <linux/errname.h>
> > > > #include <linux/mutex.h>
> > > > @@ -157,6 +158,18 @@ void rust_helper_init_work_with_key(struct
> > > > work_struct *work, work_func_t func,
> > > > }
> > > > EXPORT_SYMBOL_GPL(rust_helper_init_work_with_key);
> > > >
> > > > +void *rust_helper_dev_get_drvdata(struct device *dev)
> > > > +{
> > > > + return dev_get_drvdata(dev);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(rust_helper_dev_get_drvdata);
> > > > +
> > > > +const char *rust_helper_dev_name(const struct device *dev)
> > > > +{
> > > > + return dev_name(dev);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(rust_helper_dev_name);
> > > > +
> > > > /*
> > > > * `bindgen` binds the C `size_t` type as the Rust `usize`
> > > > type, so we can
> > > > * use it in contexts where Rust expects a `usize` like slice
> > > > (array) indices.
> > > > diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
> > > > index 9be021e393ca..7309a236f512 100644
> > > > --- a/rust/kernel/device.rs
> > > > +++ b/rust/kernel/device.rs
> > > > @@ -4,7 +4,7 @@
> > > > //!
> > > > //! C header:
> > > > [`include/linux/device.h`](../../../../include/linux/device.h)
> > > >
> > > > -use crate::bindings;
> > > > +use crate::{bindings, str::CStr};
> > > >
> > > > /// A raw device.
> > > > ///
> > > > @@ -20,4 +20,78 @@
> > > > pub unsafe trait RawDevice {
> > > > /// Returns the raw `struct device` related to `self`.
> > > > fn raw_device(&self) -> *mut bindings::device;
> > > > +
> > > > + /// Returns the name of the device.
> > > > + fn name(&self) -> &CStr {
> > > > + let ptr = self.raw_device();
> > > > +
> > > > + // SAFETY: `ptr` is valid because `self` keeps it
> > > > alive.
> > >
> > > How can self keep it alive?
> > >
> > > > + let name = unsafe { bindings::dev_name(ptr) };
> > > > +
> > > > + // SAFETY: The name of the device remains valid while
> > > > it is alive (because the device is
> > > > + // never renamed, per the safety requirement of this
> > > > trait). This is guaranteed to be the
> > > > + // case because the reference to `self` outlives the
> > > > one of the returned `CStr` (enforced
> > > > + // by the compiler because of their lifetimes).
> > >
> > > devices are renamed all the time, I don't understand how this can
> > > be
> > > true here.
> >
> > This was discussed before:
> > https://lore.kernel.org/lkml/ZAnB%2FDozWsir1cIE@kroah.com/
> >
> > I even sent a patch (that Greg applied) that fixes the C comment
> > that
> > lead to the safety comment above:
> > https://lore.kernel.org/lkml/20230406045435.19452-1-wedsonaf@gmail.com/
> >
> > The decision then was to remove the `name` method until some driver
> > actually needed it. (We had no plans to upstream the one that used
> > it
> > in the rust branch, pl061 gpio.)
>
> Ah, I thought I had reviewed all of this before, thanks for pointing
> this out. And sad that nothing really changed since then, I'll just
> ignore all of this thread for now someone figures out how to act on
> review comments that are made.
>
> Ignoring them for a year and resending the lot just wastes everyone's
> time :(
Hi,
I'd ask for some generosity here – as you might have noticed, there's
now a "new team" dedicating their time to these efforts, in addition to
those who have been working on it for longer.
Danilo spent a very great amount of time just collecting commits,
contacting the authors and coordinating with them, gather all the
downstream branches, make sure they build warning-free and work with a
test driver, try to understand the existing code base etc. etc. pp.
It's really a lot of work and some things might be looked over. It's
not as if anyone "ignored [the feedback] for a year", it's more that
it's several parties scattered over several companies, with some of the
parties having dropped out by now.
With that being said, your help and feedback is extremely valuable, so
keeping that process going would be neat :)
Regarding the feedback from the thread from a year ago: Assuming we
implement as much of that as possible, could we get back at you with
follow up questions and discussions here in this thread?
Thanks,
P.
>
> greg k-h
>
next prev parent reply other threads:[~2024-03-27 9:05 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 17:49 [PATCH 0/8] [RFC] Rust device / driver abstractions Danilo Krummrich
2024-03-25 17:49 ` [PATCH 1/8] arch: x86: tools: increase symbol name size Danilo Krummrich
2024-03-25 17:53 ` Miguel Ojeda
2024-03-25 18:01 ` Danilo Krummrich
2024-03-25 18:18 ` Miguel Ojeda
2024-03-25 17:49 ` [PATCH 2/8] rust: device: Add a minimal RawDevice trait Danilo Krummrich
2024-03-25 18:14 ` Greg KH
2024-03-25 18:22 ` Miguel Ojeda
2024-03-26 22:38 ` Danilo Krummrich
2024-03-27 5:25 ` Greg KH
2024-03-27 11:39 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 3/8] rust: device: Add a stub abstraction for devices Danilo Krummrich
2024-03-25 17:58 ` Boqun Feng
2024-03-27 11:36 ` Danilo Krummrich
2024-03-25 18:14 ` Greg KH
2024-03-25 18:17 ` Greg KH
2024-03-26 16:01 ` Danilo Krummrich
2024-03-26 18:03 ` Greg KH
2024-03-26 19:03 ` Boqun Feng
2024-03-26 21:01 ` Danilo Krummrich
2024-03-27 1:38 ` Wedson Almeida Filho
2024-03-27 5:22 ` Greg KH
2024-03-27 9:05 ` Philipp Stanner [this message]
2024-03-27 9:13 ` Greg KH
2024-03-27 11:35 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 4/8] rust: add driver abstraction Danilo Krummrich
2024-03-25 18:12 ` Greg KH
2024-03-25 18:30 ` Greg KH
2024-03-25 19:36 ` David Airlie
2024-03-26 5:37 ` Greg KH
2024-03-26 6:02 ` David Airlie
2024-03-26 6:14 ` Greg KH
2024-03-26 6:34 ` David Airlie
2024-03-31 19:17 ` Fabien Parent
2024-04-02 13:51 ` Danilo Krummrich
2024-03-28 10:41 ` Viresh Kumar
2024-03-25 17:49 ` [PATCH 5/8] rust: add rcu abstraction Danilo Krummrich
2024-03-25 17:49 ` [PATCH 6/8] rust: add revocable mutex Danilo Krummrich
2024-03-25 18:22 ` Greg KH
2024-03-26 18:13 ` Danilo Krummrich
2024-03-26 18:17 ` Greg KH
2024-03-26 21:32 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 7/8] rust: add revocable objects Danilo Krummrich
2024-03-25 18:21 ` Greg KH
2024-03-26 17:07 ` Danilo Krummrich
2024-03-26 18:16 ` Greg KH
2024-03-26 21:48 ` Danilo Krummrich
2024-03-27 1:31 ` Wedson Almeida Filho
2024-03-25 17:49 ` [PATCH 8/8] rust: add device::Data Danilo Krummrich
2024-03-25 18:21 ` Greg KH
2024-03-26 16:54 ` Danilo Krummrich
2024-03-26 18:12 ` Greg KH
2024-03-26 22:24 ` 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=dc21d9dc9be739122e60caefa0f75ac29bd2a3c7.camel@redhat.com \
--to=pstanner@redhat.com \
--cc=a.hindborg@samsung.com \
--cc=airlied@redhat.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=boqun.feng@gmail.com \
--cc=bp@alien8.de \
--cc=dakr@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=lina@asahilina.net \
--cc=lyude@redhat.com \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wedsonaf@gmail.com \
--cc=x86@kernel.org \
/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).