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

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

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?  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 (and
they can: the core SCSI model looks beguilingly simple).  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.  Just because it's in rust doesn't change that
calculus ... and you're by no means the first people to try this, so
listen to the voices of experience and don't.

Regards,

James