Re: Universal Flash Storage Driver Proposal

Hey sorry for taking a while to reply...

On Wed, Jan 22, 2025 at 7:42 PM Jaeyoon Choi <j_yoon.choi@samsung.com>
wrote:

>
> > Generally, yes. However, looking at umass, you'll see that different
> kinds of USB
> > thumb drives have different subsets of SCSI that are supported. For
> example, RBC
> > is a reduced subset of commands, and umass filters things so that we
> have the right
> > length (only READ(10) and WRITE(10) are supported for RBC, for example).
> I'd image
> > there'd be a similar list for UFS and you'd need to arrange for scsi_da
> to only generate
> > those. It looks like some kind of quirk info is going on to force this,
> but I've not puzzled
> > through all the layers to find it. umass also does some minor CDB
> rewriting for things
> > like ATAPI that are close. UFI also has a different subset that's
> supported.
>
> Thanks for letting me know, I will study the scsi_da code more.
>
> > Right now that's all handled by the SIM setting cpi.hba_misc |=
> PIM_NO_6_BYTE for
> > the CAM_PATH_INQ xpt request. You may need to create a PIM_NO_10_BYTE if
> > only the 12 byte variants are supported, or find some other way to
> signal to scsi_da that
> > it must choose a different way to generate commands (if say a single bit
> isn't enough,
> > or it turns into too much of a specialty quirk flag)
>
> There are three restrictions that I found in UFS spec (MODE SENSE(6),
> READ(12)
> and WRITE(12)),
> I think adding the following two flags to cpi.hba_misc should be enough:
> - PIM_NO_12_BYTE
> - PIM_NO_6_BYTE_MODE_SENSE
> But I'll take a look at the UFS spec documentation to see if there are more
> restrictions needed.
>

I've been studying UMASS and have a different idea. I'm starting to not
like the PIM flags
now that I've read it.

There's about a dozen commands that different USB flash devices can't do in
various ways.
I've started to convert umass to just fail the command as illegal when a
bad command is
sent to it. I've also been modifying the da, cd, etc drivers to notice the
illegal commands and
modify its behavior. It isn't a new idea: the periph drivers have been
doing it to cope with
drives that don't support READ(6) commands. It's recently (in the last 5
years) expanded to
dealing with other commands like SYNCHRONIZE CACHE, MODE SENSE.

The idea is to allow the device to reject the command as illegal. In the
cases of reduced SCSI
command sets, like RBC, UFS, etc the SIM should reject known bad commands
at the SIM
layer because history has shown that some of the
lower-quality-but-still-working-enough drives
can hang when unexpected commands are sent to them.

Not supporting MODE SENSE(6) likely is going to be a somewhat larger change.

> Though having said that, I kinda think
> > we can retire all the 6-byte command support: we don't need it on
> anything modern and
> > it really is there for the pre-scsi-1 SASI drives that we don't
> support[*]. We may also want
> > to rework the number of special cases we have in scsi_da.c as well.
> There's a number
> > of quirks that either go away with no-6-byte commands, or that can be
> guessed w/o a loud
> > message to the user (which is why we avoid sending them with the quirk,
> though some
> > of that avoidance is because some early drives hung).
>
> I don't know if this helps, but Fuchsia OS has decided not to support
> READ(6)/WRITE(6) commands.
> (Fuchsia's SCSI layer is still in the early stages of development)
> -
> https://fuchsia-review.googlesource.com/c/fuchsia/+/932832/comments/72826c28_c48b071d?tab=comments


Yes. Once upon a time, there was limited space for CDBs in HBAs. So it made
a lot of
sense to send the smallest CDB possible to the SIM for that HBA. Those days
were in the
90s and early 2000s. We have a few hundred devices that are quirked to not
use 6-byte
commands, so I think that's a wise decision.

> So the SCSI protocol likely can still be used, but some adjustments might
> be needed
> > to the SCSI transport (though the distinction between the two can get
> rather confused at
> > times).  Eg, I think eventually you'll find you'll want a XPORT_UFS to
> sit along side
> > XPORT_FC, XPORT_SPI, XPORT_SAS, etc. I think the protocol will be
> PROTO_SCSI
> > for everything. Each of the transports can and do report slightly
> different things in handled
> > by XPT_GET_TRAN_SETTINGS and XPT_SET_TRAN_SETTINGS messages.
>
> I was confusing SCSI protocol and SCSI transport. Thanks for the
> clarification.
> I agree with you that we should add XPORT_UFS. I will study it more and
> share
> my design.
>
> > I hope my advice is useful. Also, although I've given talks on this
> topic, you should double
> > check anything I said in those talks or that I say here. (a) It will
> help you learn CAM better
> > and (b) some of these details I only think I know and understand, but
> I'm missing something
> > subtle (if I knew which points, I'd say :).
> >
> > Good luck with everything, and don't hesitate to ask if you have
> questions, want some early
> > code review, design advice, etc.
>
> I was confused and your advice cleared up a lot of my questions.
> I will definitely check out your talks again.
>
> Here are a few questions that come to mind:
> 1. i'm trying to take the overall structure similar to NVMe, is that okay?
>    (nvme_controller, nvme_namespace, nvme_qpair, nvme_request,
> nvme_tracker,
>    etc.)
>

For the UFS HBA device, I think that's a good approach. Most devices these
days have tried to de-couple request submission and request completion.
While
our NVME driver may have some odd quirks in it around these concepts due to
early NVMe drives falling short of the ideal, I think it's a good model to
follow.


> 2. is there any tool or test I can try to test the block device while I'm
>    developing, I'm curious to know how you are testing it.
>

Test how? I'm not sure I understand this question well enough to answer,
so maybe a few examples will help me focus an answer.


> FYI, I'll be out of the office for 5 weeks starting in February, so I'll
> probably start development in mid-March.
> Perhaps I can ask more detailed questions at that time.
>

Excellent. This should be waiting for you when you return in a couple
of weeks. I hadn't read to the end to know you'd be out, or I would have
tried harder to send this sooner (work has been busy).

In the mean time, I'll see if I can locate a copy of the UFS standard
or a reasonable summary. The ones at jedec.org are a bit too expensive
for me to buy on my own. I've found excerpts of it datasheets at best, which
may suffice for my review needs.

Warner