[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v7mz7e4z.fsf@kernel.org>
Date: Thu, 07 Aug 2025 10:02:52 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Boqun Feng <boqun.feng@...il.com>, Miguel Ojeda <ojeda@...nel.org>, Alex
Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>, Björn Roy
Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, Alice
Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, Danilo
Krummrich <dakr@...nel.org>, Jens Axboe <axboe@...nel.dk>,
linux-block@...r.kernel.org, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 12/16] rnull: enable configuration via `configfs`
"Daniel Almeida" <daniel.almeida@...labora.com> writes:
>> On 11 Jul 2025, at 08:43, Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>> Allow rust null block devices to be configured and instantiated via
>> `configfs`.
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@...nel.org>
>> ---
>> drivers/block/rnull/Kconfig | 2 +-
>> drivers/block/rnull/configfs.rs | 220 +++++++++++++++++++++++++++++++++++++++
>> drivers/block/rnull/rnull.rs | 58 ++++++-----
>> rust/kernel/block/mq/gen_disk.rs | 2 +-
>> 4 files changed, 253 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/block/rnull/Kconfig b/drivers/block/rnull/Kconfig
>> index 6dc5aff96bf4..7bc5b376c128 100644
>> --- a/drivers/block/rnull/Kconfig
>> +++ b/drivers/block/rnull/Kconfig
>> @@ -4,7 +4,7 @@
>>
>> config BLK_DEV_RUST_NULL
>> tristate "Rust null block driver (Experimental)"
>> - depends on RUST
>> + depends on RUST && CONFIGFS_FS
>
> Should this really be a dependency? IIUC, the driver still works with this
> unset, it just doesn’t have this feature?
It does not and I do not intend for it to operate without configfs.
I did not try to build without configfs enabled, but the rnull driver
has calls to symbols provided by the configfs subsystem, so it really
should not work without configfs loaded.
>
>> help
>> This is the Rust implementation of the null block driver. Like
>> the C version, the driver allows the user to create virutal block
>> diff --git a/drivers/block/rnull/configfs.rs b/drivers/block/rnull/configfs.rs
>> new file mode 100644
>> index 000000000000..6c0e3bbb36ec
>> --- /dev/null
>> +++ b/drivers/block/rnull/configfs.rs
>> @@ -0,0 +1,220 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +use super::{NullBlkDevice, THIS_MODULE};
>> +use core::fmt::Write;
>> +use kernel::{
>> + block::mq::gen_disk::{GenDisk, GenDiskBuilder},
>> + c_str,
>> + configfs::{self, AttributeOperations},
>> + configfs_attrs, new_mutex,
>> + page::PAGE_SIZE,
>> + prelude::*,
>> + str::CString,
>> + sync::Mutex,
>> +};
>> +use pin_init::PinInit;
>> +
>> +pub(crate) fn subsystem() -> impl PinInit<kernel::configfs::Subsystem<Config>, Error> {
>> + let item_type = configfs_attrs! {
>> + container: configfs::Subsystem<Config>,
>> + data: Config,
>> + child: DeviceConfig,
>> + attributes: [
>> + features: 0,
>> + ],
>> + };
>> +
>> + kernel::configfs::Subsystem::new(c_str!("rnull"), item_type, try_pin_init!(Config {}))
>> +}
>> +
>> +#[pin_data]
>> +pub(crate) struct Config {}
>
> This still builds:
>
> diff --git a/drivers/block/rnull/configfs.rs b/drivers/block/rnull/configfs.rs
> index 3ae84dfc8d62..2e5ffa82e679 100644
> --- a/drivers/block/rnull/configfs.rs
> +++ b/drivers/block/rnull/configfs.rs
> @@ -24,10 +24,9 @@ pub(crate) fn subsystem() -> impl PinInit<kernel::configfs::Subsystem<Config>, E
> ],
> };
>
> - kernel::configfs::Subsystem::new(c_str!("rnull"), item_type, try_pin_init!(Config {}))
> + kernel::configfs::Subsystem::new(c_str!("rnull"), item_type, Config {})
> }
>
> -#[pin_data]
> pub(crate) struct Config {}
>
> Perhaps due to:
>
> // SAFETY: the `__pinned_init` function always returns `Ok(())` and initializes every field of
> // `slot`. Additionally, all pinning invariants of `T` are upheld.
> unsafe impl<T> PinInit<T> for T {
> unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), Infallible> {
> // SAFETY: `slot` is valid for writes by the safety requirements of this function.
> unsafe { slot.write(self) };
> Ok(())
> }
> }
Hmm, when I apply this change it does not work out for me:
RUSTC [M] drivers/block/rnull/rnull.o
error[E0277]: the trait bound `Config: PinInit<Config, kernel::error::Error>` is not satisfied
--> /home/aeh/src/linux-rust/rnull-up-v6.16-rc1/drivers/block/rnull/configfs.rs:27:66
|
27 | kernel::configfs::Subsystem::new(c_str!("rnull"), item_type, Config {})
| -------------------------------- ^^^^^^^^^ the trait `PinInit<Config, kernel::error::Error>` is not implemented for `Config`
| |
| required by a bound introduced by this call
|
= help: the following other types implement trait `PinInit<T, E>`:
<AlwaysFail<T> as PinInit<T, ()>>
<ChainPinInit<I, F, T, E> as PinInit<T, E>>
<ChainInit<I, F, T, E> as PinInit<T, E>>
<core::result::Result<T, E> as PinInit<T, E>>
note: required by a bound in `Subsystem::<Data>::new`
--> /home/aeh/src/linux-rust/rnull-up-v6.16-rc1/rust/kernel/configfs.rs:151:20
|
148 | pub fn new(
| --- required by a bound in this associated function
...
151 | data: impl PinInit<Data, Error>,
| ^^^^^^^^^^^^^^^^^^^^ required by this bound in `Subsystem::<Data>::new`
error[E0277]: the trait bound `Config: PinInit<Config, kernel::error::Error>` is not satisfied
--> /home/aeh/src/linux-rust/rnull-up-v6.16-rc1/drivers/block/rnull/configfs.rs:17:30
|
17 | pub(crate) fn subsystem() -> impl PinInit<kernel::configfs::Subsystem<Config>, Error> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `PinInit<Config, kernel::error::Error>` is not implemented for `Config`
|
= help: the following other types implement trait `PinInit<T, E>`:
<AlwaysFail<T> as PinInit<T, ()>>
<ChainPinInit<I, F, T, E> as PinInit<T, E>>
<ChainInit<I, F, T, E> as PinInit<T, E>>
<core::result::Result<T, E> as PinInit<T, E>>
note: required by a bound in `Subsystem::<Data>::new`
--> /home/aeh/src/linux-rust/rnull-up-v6.16-rc1/rust/kernel/configfs.rs:151:20
|
148 | pub fn new(
| --- required by a bound in this associated function
...
151 | data: impl PinInit<Data, Error>,
| ^^^^^^^^^^^^^^^^^^^^ required by this bound in `Subsystem::<Data>::new`
error: aborting due to 2 previous errors
I rebased on rust-6.17. What did you apply this series to?
>
>
>> +
>> +#[vtable]
>> +impl AttributeOperations<0> for Config {
>> + type Data = Config;
>> +
>> + fn show(_this: &Config, page: &mut [u8; PAGE_SIZE]) -> Result<usize> {
>> + let mut writer = kernel::str::Formatter::new(page);
>> + writer.write_str("blocksize,size,rotational\n")?;
>> + Ok(writer.bytes_written())
>> + }
>> +}
>> +
>> +#[vtable]
>> +impl configfs::GroupOperations for Config {
>> + type Child = DeviceConfig;
>> +
>> + fn make_group(
>> + &self,
>> + name: &CStr,
>> + ) -> Result<impl PinInit<configfs::Group<DeviceConfig>, Error>> {
>> + let item_type = configfs_attrs! {
>> + container: configfs::Group<DeviceConfig>,
>> + data: DeviceConfig,
>> + attributes: [
>> + // Named for compatibility with C null_blk
>> + power: 0,
>> + blocksize: 1,
>> + rotational: 2,
>> + size: 3,
>> + ],
>> + };
>> +
>> + Ok(configfs::Group::new(
>> + name.try_into()?,
>> + item_type,
>> + // TODO: cannot coerce new_mutex!() to impl PinInit<_, Error>, so put mutex inside
>
> Isn’t this related to [0] ?
No, I think this is a type inference problem.
>
>
>> + try_pin_init!( DeviceConfig {
>> + data <- new_mutex!( DeviceConfigInner {
>> + powered: false,
>> + block_size: 4096,
>> + rotational: false,
>> + disk: None,
>> + capacity_mib: 4096,
>> + name: name.try_into()?,
>> + }),
>> + }),
>> + ))
>> + }
>> +}
>> +
>> +#[pin_data]
>> +pub(crate) struct DeviceConfig {
>> + #[pin]
>> + data: Mutex<DeviceConfigInner>,
>> +}
>> +
>> +#[pin_data]
>> +struct DeviceConfigInner {
>> + powered: bool,
>> + name: CString,
>> + block_size: u32,
>> + rotational: bool,
>> + capacity_mib: u64,
>> + disk: Option<GenDisk<NullBlkDevice>>,
>> +}
>> +
>> +#[vtable]
>> +impl configfs::AttributeOperations<0> for DeviceConfig {
>> + type Data = DeviceConfig;
>> +
>> + fn show(this: &DeviceConfig, page: &mut [u8; PAGE_SIZE]) -> Result<usize> {
>> + let mut writer = kernel::str::Formatter::new(page);
>> +
>> + if this.data.lock().powered {
>> + writer.write_fmt(fmt!("1\n"))?;
>> + } else {
>> + writer.write_fmt(fmt!("0\n"))?;
>> + }
>> +
>> + Ok(writer.bytes_written())
>> + }
>> +
>> + fn store(this: &DeviceConfig, page: &[u8]) -> Result {
>> + let power_op: bool = core::str::from_utf8(page)?
>> + .trim()
>> + .parse::<u8>()
>> + .map_err(|_| kernel::error::code::EINVAL)?
>
> nit: I’d import that if I were you, but it’s your call.
OK.
>
>> + != 0;
>> +
>> + let mut guard = this.data.lock();
>> +
>> + if !guard.powered && power_op {
>> + guard.disk = Some(NullBlkDevice::new(
>> + &guard.name,
>> + guard.block_size,
>> + guard.rotational,
>> + guard.capacity_mib,
>> + )?);
>> + guard.powered = true;
>> + } else if guard.powered && !power_op {
>> + drop(guard.disk.take());
>> + guard.powered = false;
>> + }
>
> nit: the guard is not used here, but it is still alive. This is harmless in
> this case, but as I general pattern, I find that using closures cuts back on
> the scope, i.e.:
>
> this.with_locked_data(|data| {
> // use the guard
> });
>
> // Guard is already free here, no surprises.
I don't see `with_locked_data` anywhere in the kernel crate? It would be
a method on `Mutex`? Or would you add the method to `DeviceConfig`?
>
>> +
>> + Ok(())
>> + }
>> +}
>> +
>> +#[vtable]
>> +impl configfs::AttributeOperations<1> for DeviceConfig {
>> + type Data = DeviceConfig;
>> +
>> + fn show(this: &DeviceConfig, page: &mut [u8; PAGE_SIZE]) -> Result<usize> {
>> + let mut writer = kernel::str::Formatter::new(page);
>> + writer.write_fmt(fmt!("{}\n", this.data.lock().block_size))?;
>> + Ok(writer.bytes_written())
>> + }
>> +
>> + fn store(this: &DeviceConfig, page: &[u8]) -> Result {
>> + if this.data.lock().powered {
>> + return Err(EBUSY);
>> + }
>> +
>> + let text = core::str::from_utf8(page)?.trim();
>> + let value = text
>> + .parse::<u32>()
>> + .map_err(|_| kernel::error::code::EINVAL)?;
>> +
>> + GenDiskBuilder::validate_block_size(value)?;
>> + this.data.lock().block_size = value;
>> + Ok(())
>> + }
>> +}
>> +
>> +#[vtable]
>> +impl configfs::AttributeOperations<2> for DeviceConfig {
>> + type Data = DeviceConfig;
>> +
>> + fn show(this: &DeviceConfig, page: &mut [u8; PAGE_SIZE]) -> Result<usize> {
>> + let mut writer = kernel::str::Formatter::new(page);
>> +
>> + if this.data.lock().rotational {
>> + writer.write_fmt(fmt!("1\n"))?;
>> + } else {
>> + writer.write_fmt(fmt!("0\n"))?;
>> + }
>> +
>> + Ok(writer.bytes_written())
>> + }
>> +
>> + fn store(this: &DeviceConfig, page: &[u8]) -> Result {
>> + if this.data.lock().powered {
>> + return Err(EBUSY);
>> + }
>> +
>> + this.data.lock().rotational = core::str::from_utf8(page)?
>> + .trim()
>> + .parse::<u8>()
>> + .map_err(|_| kernel::error::code::EINVAL)?
>> + != 0;
>> +
>> + Ok(())
>> + }
>> +}
>> +
>> +#[vtable]
>> +impl configfs::AttributeOperations<3> for DeviceConfig {
>> + type Data = DeviceConfig;
>> +
>> + fn show(this: &DeviceConfig, page: &mut [u8; PAGE_SIZE]) -> Result<usize> {
>> + let mut writer = kernel::str::Formatter::new(page);
>> + writer.write_fmt(fmt!("{}\n", this.data.lock().capacity_mib))?;
>> + Ok(writer.bytes_written())
>> + }
>> +
>> + fn store(this: &DeviceConfig, page: &[u8]) -> Result {
>> + if this.data.lock().powered {
>> + return Err(EBUSY);
>> + }
>> +
>> + let text = core::str::from_utf8(page)?.trim();
>> + let value = text
>> + .parse::<u64>()
>> + .map_err(|_| kernel::error::code::EINVAL)?;
>> +
>> + this.data.lock().capacity_mib = value;
>> + Ok(())
>> + }
>> +}
>> diff --git a/drivers/block/rnull/rnull.rs b/drivers/block/rnull/rnull.rs
>> index d07e76ae2c13..d09bc77861e4 100644
>> --- a/drivers/block/rnull/rnull.rs
>> +++ b/drivers/block/rnull/rnull.rs
>> @@ -1,28 +1,26 @@
>> // SPDX-License-Identifier: GPL-2.0
>>
>> //! This is a Rust implementation of the C null block driver.
>> -//!
>> -//! Supported features:
>> -//!
>> -//! - blk-mq interface
>> -//! - direct completion
>> -//! - block size 4k
>
> Why are these three removed?
Because the list is stale and I did not want to maintain it.
Best regards,
Andreas Hindborg
Powered by blists - more mailing lists