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

[Andreas Hindborg]

"James Bottomley" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes:

> On Sat, 2026-09-12 at 13:00 +0200, Andreas Hindborg wrote:
>> "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> 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 (and
> they 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.

> Just because it's in rust doesn't change that
> calculus ...

On this I agree with you. The implementation language is not what we
should discuss.

> and you're by no means the first people to try this, so
> listen to the voices of experience and don't.

In general I do not accept arguments that take shape along the lines of
"I have x YoE doing this, therefore I am right".

While it is possible that you are in fact on to something and that your
experience is the reason for this, it does not further the discussion. I
would much rather have you explain to me the reasoning behind your
expectations for this effort.

If it is "someone did it before and it did not work out" - who did it and why
did it not work out?

We have USB MSC as an example. I was not around back then. What
happened? Was their situation the same as it is for UFS? What scsi logic
did they try to implement in their driver that was a duplicate of scsi
midlayer? Surely it was not the 300 lines of command encoding/decoding
that made them fold?

At any rate, the rationale for extracting the UFS driver is to make room
for features that fit poorly into the SCSI midlayer and which are not
standardized in T10 - without making additional work for scsi subsystem
maintainers.

Best regards,
Andreas Hindborg