Opened 13 years ago

Last modified 17 months ago

#1106 assigned enhancement

Port USB mass storage driver to new SCSI module API

Reported by: axeld Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Drivers/Disk/USB Version: R1/pre-alpha1
Keywords: Cc: siarzhuk
Blocked By: Blocking:
Platform: All


Our USB mass storage module currently only supports the R5 SCSI bus layer. Since we are not compatible with this one, it doesn't work on Haiku yet. Port the USB driver to use the new SCSI module API, and therefore, to use the new driver API as well. The disks should be published somewhere under /dev/disk/usb/ when done.

Change History (17)

comment:1 by siarzhuk, 13 years ago

Cc: siarzhuk added

comment:2 by mmlr, 13 years ago

Owner: changed from mmlr to siarzhuk

Reassigning this task to Siarzhuk Zharski as he is the author of the usb_scsi module and started looking into this already.

comment:3 by jackburton, 13 years ago

What's the status of this ? Is there some code available already ?

comment:4 by siarzhuk, 13 years ago

I'm working on it. Hope to commit something in a week or two. I'm sorry for delay.

in reply to:  4 comment:5 by jackburton, 13 years ago

Replying to siarzhuk:

I'm working on it. Hope to commit something in a week or two. I'm sorry for delay.

No need to be sorry, I just wanted to know if someone was still working on it :)

comment:6 by diver, 13 years ago

Any news, Siarzhuk?

in reply to:  6 comment:7 by siarzhuk, 13 years ago

Replying to diver:

Any news, Siarzhuk?

Hm. Is it a bug tracker or message board? :-) I'm making now a vacations in Minsk. Before the final attack to usb_scsi code. ;-)

comment:8 by emitrax, 12 years ago

Any news about the porting? :)

in reply to:  8 ; comment:9 by siarzhuk, 12 years ago

Replying to emitrax:

Any news about the porting? :)

Only troubles at the moment: Sorry :-(

in reply to:  9 comment:10 by siarzhuk, 12 years ago

comment:11 by diver, 12 years ago

Does the fact that the new driver architecture is somewhat completed should change anything in porting issues? Also mmlr wrote usb_disk module, what is the difference between it and the subject driver?

comment:12 by mmlr, 12 years ago

The difference is that usb_disk does the minimal SCSI that is required itself and directly publishes a block device to the system. The usb_scsi on the other hand is a bridge between the SCSI subsystem and the USB device. It takes SCSI commands from the SCSI subsystem and pushes them to the USB driver and back. So usb_scsi does not publish the drive itself, it gets published by the SCSI subsystem (or rather scsi_disk / scsi_cd) and then looks like a normal SCSI device to the rest of the system. This approach has a more of an overhead and generally is more complexity, but essentially reduces the amount of work usb_scsi has to do (as it is more like a pass through - not counting having to work around device bugs and translating incompatible protocols). The advantage of it being that for example a USB CD writer could be supported by the existing SCSI system and transparently through scsi_cd. When not using usb_scsi you would have to write an individual usb_cd driver that would then be publishing the CD drive and export this functionality.

On the subject of the new driver architecture. That it is in place does not change much directly. First the USB stack has also to be ported to it (while leaving the existing API intact). This alone poses a few, not yet solved, problems though. It is not yet clear to me what the best way to publish devices through the new architecture is, as there is no real model on how multi function devices are supposed to be presented.

When the USB stack is available through the new driver architecture this does still not mean that usb_scsi is available. It only solves the problem of when it gets loaded and by whom. The real work is still, as would be right now, porting the usb_scsi driver to the new SCSI interface. Incidentally moving to the new driver architecture makes it more work, as also the USB part has to be ported (the USB interface would have been the same with the old model, avoiding the need to port).

Since usb_disk works good enough for now (and in fact, as other protocols are not too common in newer devices anymore because they are discouraged by Microsoft for example, it should be pretty future proof), I don't think that this task is highly urgent. Eventually it will make sense to port it for the aforementioned advantages it brings though.

comment:13 by siarzhuk, 5 years ago

Owner: changed from siarzhuk to nobody
Status: newassigned

comment:14 by waddlesplash, 19 months ago

Milestone: R1R2

comment:15 by pulkomandy, 19 months ago

Hi waddlesplash,

Can you explain why this is moved to R2? My understanding is that R2 is for tickets that will need ABI breakage, and we use "unscheduled" for things we don't think are needed for R1.

Also, some notes on this:

At BeGeistert oco let me test things on his 2TB USB drive. This doesn't work with our current USB mass storage driver because we use only 32 bit sector commands. However, the SCSI module uses only 64 bit commands, and these are not mandatory in SCSI, so it will probably not work with at least some devices.

I think it would be nice to clean this up and make the needed changes to the SCSI and USB modules, so we can fix that in the long term way and possibly for other mass storage devices using SCSI commands too.

comment:16 by waddlesplash, 18 months ago

Milestone: R2Unscheduled

Probably I just misclicked.

comment:17 by waddlesplash, 17 months ago

Component: Drivers/USBDrivers/Disk/USB
Note: See TracTickets for help on using tickets.