Re: [PATCH v8 0/7] rust: extend `module!` macro with integer parameter support

"Daniel Gomez" [off-list ref] writes:

Hi,
On Thu, Feb 27, 2025 at 03:38:06PM +0100, Andreas Hindborg wrote:

quoted

Extend the `module!` macro with support module parameters. Also add some string
to integer parsing functions and updates `BStr` with a method to strip a string
prefix.

Based on code by Adam Bratschi-Kaye lifted from the original `rust` branch [1].

Link: https://github.com/Rust-for-Linux/linux/tree/bc22545f38d74473cfef3e9fd65432733435b79f [1]
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>

I've tested this series including the following patches from Andreas' tree [1]
as dependency for module testing parameters with the Rust Null Block driver:

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/linux.git/log/?h=rnull-v6.14-rc1

51d304103b7f rust: refactor: rename `RawWriter` to `BufferWriter`
544811b24574 LIST: [PATCH v2 1/3] rust: sync: change `<Arc<T> as ForeignOwnable>::PointedTo` to `T`
3f097abd58de LIST: [PATCH v15 1/3] rust: types: add `ForeignOwnable::PointedTo`
0525eda0ff8d LIST: [PATCH v7 3/14] rust: sync: add `Arc::as_ptr`
ce7343b48e63 LIST: [PATCH v2 2/3] rust: configfs: introduce rust support for configfs
6efae1a9a226 rust: rnull: add module parameter support
b6545e0eaf94 rust: rnull: enable configuration via `configfs`
6a3bc0dc31d0 rust: rnull: move driver to separate directory

* modinfo
sudo modinfo rnull_mod
filename:       /lib/modules/6.14.0-rc6-00015-g51d304103b7f/kernel/drivers/block/rnull/rnull_mod.ko
author:         Andreas Hindborg
description:    Rust implementation of the C null block driver
license:        GPL v2
name:           rnull_mod
intree:         Y
depends:
vermagic:       6.14.0-rc6-00015-g51d304103b7f mod_unload modversions
parm:           nr_devices:Number of devices to register (u64)
parm:           bs:Block size (in bytes) (u32)
parm:           rotational:Set the rotational feature for the device (0 for false, 1 for true). Default: 0 (u8)
parm:           gb:Device capacity in MiB (u64)

* Testing nr_devices parameter:
sudo modprobe rnull_mod nr_devices=100

sudo ls /dev/rnullb* | wc -l
100

* Testing block size and capacity parameters:
sudo rmmod rnull_mod
sudo modprobe rnull_mod nr_devices=1 bs=512 gb=1024

sudo fdisk -l /dev/rnullb0
Disk /dev/rnullb0: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

* Testing block size with fio and blkalgn [1] (tool for validating driver block
size):

[1] blkalgn is an eBPF-based tool for tracing block operations that also reports
block granularity and alignment histograms:
https://github.com/dkruces/bcc/tree/blkalgn

Install:
https://github.com/dkruces/bcc/releases/latest/download/blkalgn-$(uname -m) \
--output /usr/sbin/blkalgn \
&& sudo chmod +x /usr/sbin/blkalgn

sudo modprobe rnull_mod nr_devices=1 bs=1024 gb=1024
sudo curl --location \

sudo blkalgn --disk=rnullb0 --ops=Write
sudo fio --name=test --direct=1 --rw=write --bs=1024 --size=512k \
--filename=/dev/rnullb0 --loop=1000

I/O Granularity Histogram for Device rnullb0 (lbads: 10 - 1024 bytes)
Total I/Os: 10748
     Bytes         : count    distribution
        1024       : 10748    |****************************************|

I/O Alignment Histogram for Device rnullb0
     Bytes               : count    distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 0        |                                        |
        16 -> 31         : 0        |                                        |
        32 -> 63         : 0        |                                        |
        64 -> 127        : 0        |                                        |
       128 -> 255        : 0        |                                        |
       256 -> 511        : 0        |                                        |
       512 -> 1023       : 0        |                                        |
      1024 -> 2047       : 10748    |****************************************|

Tested-by: Daniel Gomez <redacted>


Andreas, Petr, Miguel,

Based on the discussion in v7, it seems that all these patches will go through
the Rust tree. Is that correct? What would be missing from the module's side?

I agree with Petr in that thread that if the changes are mostly limited to
rust-module files, they can go through the module's tree. However, that is not
the case yet.

As far as I understand, Miguel would take patch 1-5 for v6.15 and
modules would take patch 6-7 for v6.16. At least that is my
understanding from [1], @Petr and @Miguel please correct me if I am
wrong.


Best regards,
Andreas Hindborg

[1] https://lore.kernel.org/all/CANiq72mW94Y-bsJFMHqF8fbXhvAizEn7-NnxawTW+5brbxJHBg@mail.gmail.com (local)