Port USB mass storage driver to new SCSI module API

[axeld]

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.

[mmlr]

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

[jackburton]

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

[siarzhuk]

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

[jackburton]

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 :)

[diver]

Any news, Siarzhuk?

[siarzhuk]

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. ;-)

[emitrax]

Any news about the porting? :)

[siarzhuk]

Replying to emitrax:

Any news about the porting? :)

Only troubles at the moment: ​http://www.freelists.org/archives/haiku-development/12-2007/msg00044.html Sorry :-(

[siarzhuk]

Replying to siarzhuk:

Replying to emitrax:

Any news about the porting? :)

Only troubles at the moment: ​http://www.freelists.org/archives/haiku-development/12-2007/msg00044.html Sorry :-(

​http://www.freelists.org/archives/haiku-development/01-2008/msg00016.html

[diver]

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?

[mmlr]

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.

[pulkomandy]

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.

[waddlesplash]

Probably I just misclicked.