Re: [PATCH RFC] drivers/rufs: add Rust UFS host controller driver

[Bart Van Assche <bvanassche@acm.org>]

On 9/11/26 8:52 AM, Jaemyung Lee via B4 Relay wrote:
> Add a Rust UFS host controller driver that exposes UFS logical units as
> native blk-mq block devices without depending on the SCSI midlayer.

One of the goals in the Linux kernel is *not* to duplicate code.
Decoupling the UFS driver from the SCSI mid-layer implies duplicating
the functionality of the SCSI mid-layer. I do not agree with this.

> The driver is written in Rust.

Most UFS driver contributors are not familiar with Rust so I think the
choice of Rust will make this driver unpopular.

> The existing UFS driver is built on the SCSI subsystem. That made sense
> historically: UFS adopted the SCSI Architecture Model as its application
> layer, so reusing the SCSI midlayer's command queuing, error handling,
> power management, and logical-unit addressing let UFS reach Linux quickly
> and reliably. ufshcd bridges the SCSI midlayer to UFS Protocol Information
> Units.
> 
> That foundation has become a source of friction. The evolution of UFS is
> governed by JEDEC and increasingly includes UFS-specific features outside
> the SCSI command set standardized by T10.

Huh? As long as I was attending JEDEC meetings I insisted on using
commands already standardized by T10 and *not* introducing new commands.

I do not want to give UFS vendors the freedom to introduce new commands
without coordinating with a standards body that has more experience with
the introduction of new commands, e.g. T10.

Linux filesystems support the NVMe and SCSI command sets via the
abstractions offered by the block layer. Introducing new types of
storage commands would require that the block layer and all filesystems
are modified. I have not yet seen an good example of a new command that
warrants such changes.

> On Intel UFS 2.1 hardware, 4 KiB direct io_uring at QD32/job gave
> these optimized-mode ranges over 1/2/4 jobs (three samples):
> 
>    Workload  Op     RUFS kIOPS   C kIOPS      Difference
>    --------  -----  -----------  -----------  ---------------
>    randread  read   48.91-61.26  41.56-41.60  +17.6% to +47.4%
>    randwrite write  8.19-8.30    8.21-8.22    -0.4% to +1.1%
>    randrw    read   5.26-5.34    5.28-5.38    -0.9% to -0.4%
>    randrw    write  5.27-5.34    5.29-5.37    -0.8% to -0.5%

"Intel UFS 2.1" sounds weird to me since Intel never produced any UFS
devices as far as I know. Did you perhaps want to write "Intel UFSHCI
2.1"? If so, these measurements are not representative since UFSHCI
2.1 does not support MCQ. Measurement results for legacy (SDB) mode
are highly sensitive to whether or not the I/O submitter runs on the
same CPU core as the completion interrupt.

Bart.