Re: Universal Flash Storage Driver Proposal
- Reply: Warner Losh : "Re: Universal Flash Storage Driver Proposal"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 23 Jan 2025 02:42:07 UTC
> 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. > 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 > 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.) 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. 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. Thank you, Jaeyoon