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

[Jaemyung Lee]

> Since my question has not been answered, I assume that REQ_OP_DRV_IN and
> REQ_OP_DRV_OUT are sufficient. If REQ_OP_DRV_IN and REQ_OP_DRV_OUT are
> sufficient, there is no longer a reason to implement a new UFS driver
> subsystem because the upstream UFS driver already supports these
> operations, isn't it?

For a private device command, I agree that `REQ_OP_DRV_IN` and
`REQ_OP_DRV_OUT`, or an existing UFS management interface, may be
sufficient. The purpose of this RFC is not to let vendors add commands
without JEDEC, T10, block-layer, or filesystem review.

The RFC statement that there are features which do not fit the SCSI
mid-layer was too broad as written. It did not give a concrete example,
and the RFC does not establish that a new subsystem is required.

I reviewed the feature examples we had in mind. Some, such as WriteBooster
partial flush, fit the existing UFS Query and sysfs paths. The public FBO
review also does not show that SCSI blocked the feature; it raised code
reuse, ABI, userspace design, and implementation issues.

The clearest public integration issue I found is zoned UFS command
selection. The earlier discussion about using READ(10) and WRITE(10) for
zoned UFS exposed a conflict with the ZBC requirement to use the 16-byte
commands for a `TYPE_ZBC` device. This is a real JEDEC/T10 integration
question, but it can still have a focused solution in the existing stack.
It does not by itself justify another UFS subsystem.

One of my main motivations came from product work. Following one failure
often required reconstructing UFS, SCSI, block, and device-PM state and
callback ordering. RUFS tests whether a UFS-focused request, recovery, and
PM model can reduce that coordination.

The current RFC cannot demonstrate this because the complete EH, PM, and
userspace compatibility paths are missing. I think the next evaluation
must also compare against improving `ufshcd`, including focused UFS hooks,
rather than assume that direct blk-mq integration is the answer.

At this stage, I do not think the standalone architecture should be
presented as an established requirement. The next step should be to
document concrete cases and compare the responsibilities of both designs
before investing in a complete second implementation. If the same problems
can be solved cleanly in the existing driver, or if RUFS only duplicates
the existing logic, then a new subsystem is not justified.

Your comments on the benchmark are also valid. The test system was an
Intel UFSHCI 2.1 controller with a Samsung UFS device, so it tested SDB
only. The randread result had high variation and CPU/IRQ affinity was
not controlled well enough for a strong comparison. The data should be
treated only as an early real-device normal-I/O check.

Regards,
Jaemyung