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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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 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.  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.

Regards,

James