Opened 4 years ago

Last modified 7 months ago

#11972 new enhancement

support UAS (USB Attached SCSI)

Reported by: pulkomandy Owned by: nobody
Priority: low Milestone: Unscheduled
Component: Drivers/Disk/SCSI Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This was introduced with USB3 and is an alternative to the traditional and quirky USB Mass Storage. It allows better performance as SCSI commands can be queued and executed out of order by the device.

http://en.wikipedia.org/wiki/USB_Attached_SCSI

Support is available in Windows 8, Mac OS X 10.8, and Linux (not sure which version). UAS can be implemented over USB 2.0 as well.

Change History (11)

comment:1 Changed 14 months ago by waddlesplash

Component: Drivers/DiskDrivers/Disk/SCSI

comment:2 Changed 8 months ago by waddlesplash

comment:3 Changed 7 months ago by pulkomandy

This is not for UAS, this is for traditional mass storage which also uses SCSI commands, but does not allow queuing and out of order execution.

comment:4 Changed 7 months ago by waddlesplash

I don't think so? I think that the "traditional mass storage which also uses SCSI commands is what the usb_disk driver handles: http://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/drivers/disk/usb/usb_disk/usb_disk.cpp#578

So I'm not sure what scsi/usb even is then. It looks like it doesn't compile anymore.

comment:5 Changed 7 months ago by pulkomandy

This code looks like it was originally developped for BeOS and is an alternate driver for USB mass storage. It was imported along with other drivers from Siarzhuk back in 2006 and wasn't much touched since:

https://git.haiku-os.org/haiku/log/src/add-ons/kernel/busses/scsi/usb

I don't know what we should do with it. It may be cleaner than our current USB mass storage driver, and apparently can handle both bulk and cbi devices (so it should work also for USB floppy drives).

Maybe someone with more memory from these days can enlightnen us?

comment:6 Changed 7 months ago by waddlesplash

On the contrary, it looks *far* messier than the current driver, and doesn't even build to boot.

We have USB floppy support from a different driver anyway (this should be folded back into the regular usb_disk driver, though.)

comment:7 Changed 7 months ago by pulkomandy

Yes, usb_floppy should be merged with usb_disk *and* they should both be made to use the generic SCSI code instead of rolling their own thing with a subset of the commands. But, this may be a problem as using some SCSI commands will confuse some mass storage devices (eg. mobile phones, MP3 players) which implement exactly the subset of the spec used by windows mass storage drivers.

Last edited 7 months ago by pulkomandy (previous) (diff)

comment:8 Changed 7 months ago by korli

Another reason is that the USB stack isn't ported to the new driver model.

comment:9 Changed 7 months ago by mmlr

Well, maybe just look into the history:

Introduce a simple usb_disk driver that supports USB mass storage devices of
the bulk-only class using transparent SCSI commands (i.e. most of the current
external harddrives and flash media). It emulates the few SCSI commands needed
to get this sort of devices working and does not interface with the SCSI
subsystem. This makes it far easier to get working and also far better fits
how the USB stack works (as drivers can be dynamically rescanned when device
changes occur). This will allow for easy dynamic un- and replugging at runtime.

Note that this was way back in 2008. The situation then was that many USB mass storage devices were not actually implementing the SCSI layer. They just supported a tiny subset of fixed commands (probably hardcoded in firmware) and would just completely stall if you sent them anything outside of that subset. The usb_disk driver took the approach of using the most minimal subset of commands needed to make it more universally compatible (an approach which mostly worked out).

Drivers from other operating systems at that time sometimes took the same approach, some filtered the SCSI command set and others had large and growing lists of quirks to correct per device issues.

I do not know what the state of things is today. It may be worth a try to throw full SCSI at many devices and see how it goes. From past experience I'm not all that hopeful that devices have actually gotten better though, especially seeing the price range such products often fall into.

comment:10 Changed 7 months ago by pulkomandy

Well, these old devices may still be around (one of my MP3 players is still problematic even with the current code in Haiku) so yes, maybe it's fine if it stays that way.

comment:11 in reply to:  10 Changed 7 months ago by cb88

Replying to pulkomandy:

Well, these old devices may still be around (one of my MP3 players is still problematic even with the current code in Haiku) so yes, maybe it's fine if it stays that way.

That isn't the common case, wouldn't be be much better if a quirk could be added for your device? Then other devices wouldn't end up crippled on it's account etc...and your device would probably work. Every other major OS already does this so it isn't uncharted territory. There are some interesting links here https://github.com/ligurio/openbsd-tests/wiki/Device-drivers-testing

Note: See TracTickets for help on using tickets.