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

[Andreas Hindborg <a.hindborg@kernel.org>]

"Daniel Gomez" <da.gomez@kernel.org> writes:

> Hi,
> On Thu, Feb 27, 2025 at 03:38:06PM +0100, Andreas Hindborg wrote:
>> 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 <da.gomez@samsung.com>
>
>
> 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