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

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

"James Bottomley" <James.Bottomley@HansenPartnership.com> writes:

> On Sat, 2026-09-12 at 14:48 +0200, Andreas Hindborg wrote:
>> "James Bottomley" <James.Bottomley@HansenPartnership.com> writes:
>>
>> > On Sat, 2026-09-12 at 13:00 +0200, Andreas Hindborg wrote:
>> > > "Greg KH" <gregkh@linuxfoundation.org> writes:
>> > >
>> > > > On Sat, Sep 12, 2026 at 12:52:55AM +0900, Jaemyung Lee via B4
>> > > > Relay
>> > > > wrote:
>> > > > > Comments on the decision to bypass the SCSI midlayer, the
>> > > > > blk-mq model used in its place, and the proposed prerequisite
>> > > > > API boundaries would be especially welcome.
>> > > >
>> > > > Many many years ago, the USB subsystem tried to bypass the SCSI
>> > > > midlayer for its storage driver, and while it was a "quick
>> > > > solution" at the time, in the end, it didn't work out and we
>> > > > dropped the driver as it just made no sense to keep duplicating
>> > > > all of the logic all the time.
>> > > >
>> > > > So I wouldn't recommend it, as long as UFS builds on top of the
>> > > > SCSI commands and the like, you should not attempt to duplicate
>> > > > it in a separate driver, no matter how much "simpler" it
>> > > > initially seems to be.
>> > >
>> > > The scsi related code in this driver is less than 300 lines and
>> > > is mostly struct packing/unpacking. I guess we could lift the
>> > > struct definitions from the scsi layer via bindgen. But at 280
>> > > lines I am not sure it is worth it, and it hardly counts as
>> > > duplication.
>> >
>> > You didn't actually read the above did you?
>>
>> Yes.
>>
>> > The problem isn't necessarily the duplication of code per-se it's
>> > the duplication of function without understanding the subtlety.  
>> > Every fool thinks they can duplicate the core features of SCSI in a
>> > few hundred lines (andthey can: the core SCSI model looks
>> > beguilingly simple).
>>
>> Yes, it's really just encoding/decoding. Not much semantics or logic.
>>
>> > They then usually spend years adding back the necessary corner
>> > cases and quirks before finally concluding that actually they
>> > shouldn't have tried in the first place.
>>
>> Please educate this fool then. I am curious what SCSI logic we would
>> spend years re-implementing in a detached ufshci driver.
>
> The "duplication" is incomplete (it's actually only sense code handling
> in scsi.rs, but the rest of the duplication is sprayed all over the
> driver).

The SCSI logic is the CDB encoding in scsi.rs and about 50 lines of
completion disposition in queue.rs (status to block status, unit
attention requeue). I agree that the latter is the start of what
scsi_decide_disposition and sd_done do, and that it is incomplete. What
I am not yet convinced of is that the complete version for UFS is large
or subtle compared to scsi midlayer combined with current ufshcd.

> The incompleteness is fine if you never test for it, but your
> users will run into it in the field (almost certainly in error
> handling), which is when you begin the reinvention.

Correct, the RFC deliberately leaves out recovery and task management.
We wanted to get this discussion going sooner rather than later.

Of course we would validate the driver with proper testing before
declaring it stable.

And yes, the encoding/decoding surface will expand a bit once we
implement TMF and recovery. And there would have to be a bit of logic to
handle that as well. And that logic would be similar in semantics to
code in the scsi midlayer. I doubt it will be many lines, but I feel
like I have to build it first to convince you of that.

> As Greg said, this
> is the exact path USB storage tried ... and they did it because their
> devices barely behave like SCSI ones so they seemed different enough
> that there was little overlap with core SCSI (i.e. exactly like the
> JEDEC comment in the cover letter).
>
> What I don't quite get is this isn't a criticism of the language or the
> rust project, it's a criticism of the implementation methodology of
> this particular driver; and it isn't a theoretical criticism: it's
> practical; this path has been tried before and failed.  The definition
> of insanity is doing the same thing over and expecting different
> results.

Agreed, and I did not read it as a criticism of the language.

For ub, the deprecation commit from 2012 says it was removed because
every device it handled was also handled by usb-storage. Not because the
SCSI midlayer turned out to be deep. The UFS situation is different. The
device population is a handful of vendors behind one host controller
spec.

If we expected this new driver to be a strict subset of ufshcd, we would
not build it. The reason to do it is the features that do not fit the
scsi midlayer.

Here is what I count the midlayer doing for UFS today: sense to
retry/errno disposition (scsi_decide_disposition, scsi_check_sense,
sd_done), the abort to LU reset to host reset escalation in scsi_eh with
ufshcd supplying the handlers, the sd device model (capacity, write
cache, UNMAP, runtime PM), and the SG_IO ioctl plus the scsi_device
sysfs tree. Which of these is the part you expect to take years?

Best regards,
Andreas Hindborg