From: "Benno Lossin" <lossin@kernel.org>
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: <gregkh@linuxfoundation.org>, <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@kernel.org>, <aliceryhl@google.com>,
<tmgross@umich.edu>, <chrisi.schrefl@gmail.com>,
<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/7] rust: sample: misc: implement device driver sample
Date: Sat, 31 May 2025 10:11:08 +0200 [thread overview]
Message-ID: <DAA6ZTTNP0CM.270XX92YOFGWB@kernel.org> (raw)
In-Reply-To: <aDowAzvEvrQcella@pollux>
On Sat May 31, 2025 at 12:24 AM CEST, Danilo Krummrich wrote:
> On Fri, May 30, 2025 at 10:15:37PM +0200, Benno Lossin wrote:
>> On Fri May 30, 2025 at 4:24 PM CEST, Danilo Krummrich wrote:
>> > In order to demonstrate and test a MiscDeviceRegistration with a parent
>> > device, introduce CONFIG_SAMPLE_RUST_MISC_DEVICE_WITH_PARENT.
>> >
>> > If CONFIG_SAMPLE_RUST_MISC_DEVICE_WITH_PARENT=y the misc device sample
>> > is initialized with a parent device (faux), otherwise it is initialized
>> > without a parent device, i.e. the exact same way as without this patch.
>> >
>> > Signed-off-by: Danilo Krummrich <dakr@kernel.org>
>> > ---
>> > samples/rust/Kconfig | 8 +++++
>> > samples/rust/rust_misc_device.rs | 50 +++++++++++++++++++++++++++++---
>> > 2 files changed, 54 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
>> > index b1006ab4bc3c..9948ec0939ef 100644
>> > --- a/samples/rust/Kconfig
>> > +++ b/samples/rust/Kconfig
>> > @@ -30,6 +30,14 @@ config SAMPLE_RUST_MISC_DEVICE
>> >
>> > If unsure, say N.
>> >
>> > +config SAMPLE_RUST_MISC_DEVICE_WITH_PARENT
>> > + bool "Create a misc device with a parent device"
>> > + depends on SAMPLE_RUST_MISC_DEVICE
>> > + default n
>> > + help
>> > + Say Y here if you want the misc device sample to create a misc
>> > + device with a parent device.
>> > +
>>
>> Why not create a separate file? The `cfg`s might confuse newcomers
>> looking at the sample.
>
> It would be a lot of duplicated code, unless we really *only* exercise the
> device creation and registration part, which would be a bit unfortunate, given
> that this sample is also a pretty good test.
We could separate the common parts into a single file and then
`include!` that file from the two samples. (Or if the build system
supports multi-file samples then just use that, but my gut feeling is
that it doesn't)
I really would like to avoid `cfg` in samples.
>> > config SAMPLE_RUST_PRINT
>> > tristate "Printing macros"
>> > help
>> > diff --git a/samples/rust/rust_misc_device.rs b/samples/rust/rust_misc_device.rs
>> > index 9bf1a0f64e6e..175638d6d341 100644
>> > --- a/samples/rust/rust_misc_device.rs
>> > +++ b/samples/rust/rust_misc_device.rs
>> > @@ -167,6 +167,9 @@
>> > uaccess::{UserSlice, UserSliceReader, UserSliceWriter},
>> > };
>> >
>> > +#[cfg(CONFIG_SAMPLE_RUST_MISC_DEVICE_WITH_PARENT)]
>> > +use kernel::faux;
>> > +
>> > const RUST_MISC_DEV_HELLO: u32 = _IO('|' as u32, 0x80);
>> > const RUST_MISC_DEV_GET_VALUE: u32 = _IOR::<i32>('|' as u32, 0x81);
>> > const RUST_MISC_DEV_SET_VALUE: u32 = _IOW::<i32>('|' as u32, 0x82);
>> > @@ -181,19 +184,33 @@
>> > license: "GPL",
>> > }
>> >
>> > +#[cfg(not(CONFIG_SAMPLE_RUST_MISC_DEVICE_WITH_PARENT))]
>> > #[pin_data]
>> > struct RustMiscDeviceModule {
>> > #[pin]
>> > _miscdev: MiscDeviceRegistration<RustMiscDevice>,
>> > }
>> >
>> > -impl kernel::InPlaceModule for RustMiscDeviceModule {
>> > - fn init(_module: &'static ThisModule) -> impl PinInit<Self, Error> {
>> > +#[cfg(CONFIG_SAMPLE_RUST_MISC_DEVICE_WITH_PARENT)]
>> > +struct RustMiscDeviceModule {
>> > + _faux: faux::Registration,
>> > + _miscdev: Pin<KBox<MiscDeviceRegistration<RustMiscDevice>>>,
>> > +}
>> > +
>> > +impl RustMiscDeviceModule {
>> > + fn init() -> MiscDeviceOptions {
>> > pr_info!("Initializing Rust Misc Device Sample\n");
>> >
>> > - let options = MiscDeviceOptions {
>> > + MiscDeviceOptions {
>> > name: c_str!("rust-misc-device"),
>> > - };
>> > + }
>> > + }
>> > +}
>> > +
>> > +#[cfg(not(CONFIG_SAMPLE_RUST_MISC_DEVICE_WITH_PARENT))]
>> > +impl kernel::InPlaceModule for RustMiscDeviceModule {
>> > + fn init(_module: &'static ThisModule) -> impl PinInit<Self, Error> {
>> > + let options = Self::init();
>> >
>> > try_pin_init!(Self {
>> > _miscdev <- MiscDeviceRegistration::register(
>> > @@ -205,6 +222,31 @@ fn init(_module: &'static ThisModule) -> impl PinInit<Self, Error> {
>> > }
>> > }
>> >
>> > +#[cfg(CONFIG_SAMPLE_RUST_MISC_DEVICE_WITH_PARENT)]
>> > +impl kernel::Module for RustMiscDeviceModule {
>> > + fn init(_module: &'static ThisModule) -> Result<Self> {
>> > + let options = Self::init();
>> > + let faux = faux::Registration::new(c_str!("rust-misc-device-sample"), None)?;
>> > +
>> > + // For every other bus, this would be called from Driver::probe(), which would return a
Missing '`' around Driver::probe().
>> > + // `Result<Pin<KBox<T>>>`, but faux always binds to a "dummy" driver, hence probe() is
>>
>> Not clear what `T` is supposed to be, do you mean `Self`?
>
> From the perspective of the type implementing the corresponding Driver trait it
> would indeed be `Self`. But I found it ambiguous to write `Self`, since I do *not*
> mean `RustMiscDeviceModule` with `Self`.
Yeah that makes sense, I already entered into the `impl Driver` context
:) How about we use `<T as Driver>::probe()` above and then `T` makes
sense?
Another thing: faux devices don't have a `probe` in rust, so saying "not
required" doesn't make much sense, right?
>> > + // not required.
>> > + let misc = KBox::pin_init(
>> > + MiscDeviceRegistration::register(
>> > + options,
>> > + Arc::pin_init(new_mutex!(Inner { value: 0_i32 }), GFP_KERNEL),
>> > + Some(faux.as_ref()),
>> > + ),
>> > + GFP_KERNEL,
>> > + )?;
>>
>> You could also initialize this module variation in-place. (this would
>> also require the pin-init change to reference initialized fields)
>
> Yes, I also thought about that. But this way is a bit closer to what things
> would look like within a probe() callback.
Yeah then let's do that :)
---
Cheers,
Benno
next prev parent reply other threads:[~2025-05-31 8:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-30 14:24 [PATCH 0/7] misc device: support device drivers Danilo Krummrich
2025-05-30 14:24 ` [PATCH 1/7] rust: types: support fallible PinInit types in Opaque::pin_init Danilo Krummrich
2025-05-30 16:14 ` Christian Schrefl
2025-05-30 19:29 ` Benno Lossin
2025-05-30 20:11 ` Christian Schrefl
2025-05-30 21:27 ` Benno Lossin
2025-05-30 21:52 ` Danilo Krummrich
2025-05-30 14:24 ` [PATCH 2/7] rust: revocable: support fallible PinInit types Danilo Krummrich
2025-05-30 16:15 ` Christian Schrefl
2025-05-30 19:31 ` Benno Lossin
2025-05-30 14:24 ` [PATCH 3/7] rust: devres: support fallible in-place init for data Danilo Krummrich
2025-05-30 16:18 ` Christian Schrefl
2025-05-30 19:33 ` Benno Lossin
2025-05-30 14:24 ` [PATCH 4/7] rust: faux: impl AsRef<Device<Bound>> for Registration Danilo Krummrich
2025-05-30 14:24 ` [PATCH 5/7] rust: miscdevice: properly support device drivers Danilo Krummrich
2025-05-30 17:35 ` Christian Schrefl
2025-05-30 18:38 ` Danilo Krummrich
2025-05-30 20:06 ` Benno Lossin
2025-05-30 22:17 ` Danilo Krummrich
2025-05-31 8:05 ` Benno Lossin
2025-05-31 10:33 ` Danilo Krummrich
2025-05-30 14:24 ` [PATCH 6/7] rust: miscdevice: expose the parent device as &Device<Bound> Danilo Krummrich
2025-05-31 8:27 ` Benno Lossin
2025-05-31 10:46 ` Danilo Krummrich
2025-05-31 12:10 ` Benno Lossin
2025-05-31 12:39 ` Danilo Krummrich
2025-05-31 15:23 ` Benno Lossin
2025-05-30 14:24 ` [PATCH 7/7] rust: sample: misc: implement device driver sample Danilo Krummrich
2025-05-30 20:15 ` Benno Lossin
2025-05-30 22:24 ` Danilo Krummrich
2025-05-31 8:11 ` Benno Lossin [this message]
2025-05-31 10:29 ` Danilo Krummrich
2025-05-31 12:03 ` Benno Lossin
2025-05-31 12:24 ` Danilo Krummrich
2025-05-31 11:05 ` Miguel Ojeda
2025-05-30 16:37 ` [PATCH 0/7] misc device: support device drivers Christian Schrefl
2025-05-30 17:29 ` Christian Schrefl
2025-05-30 19:24 ` Benno Lossin
2025-05-30 19:35 ` Boqun Feng
2025-05-30 19:36 ` Boqun Feng
2025-05-30 18:45 ` Danilo Krummrich
2025-05-30 19:25 ` 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=DAA6ZTTNP0CM.270XX92YOFGWB@kernel.org \
--to=lossin@kernel.org \
--cc=a.hindborg@kernel.org \
--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=chrisi.schrefl@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@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.