a beginning

Herald van der Breggen herald at breggen.xs4all.nl
Sun Dec 30 22:00:40 CET 2001

>I looked a bit at isd200.c and discovered I know nothing about USB, so I
>downloaded some PDF's from the website, but haven't found something that
>enlightened me yet. Glancing at the datafab.c, it seems quite different, 
>and a bit better comprehendible. But the difference is enormous,
>in usb.c the isd200 (and usbat2 at the moment) use ss -> proto_handler,
>while datafab.c only uses ss -> transport and ss -> transport_reset.
>Although I must say I have no clues whether this is an important
>difference. However, mdharm (who apparently knows a lot about
>usb-storage) said that isd200.c was important.
Yes, I guess he is right about that. I took a closer look to datafab and 
saw that a big difference is that datafab is handled by a standard 
"transparant scsi" handler (usb_stor_transparent_scsi_command), while 
isd200 is handled by a handler defined in the driver 
(isd200_ata_command). Since usbat2 is has not scsi-like commands, but 
ata-like commands, I am afraid the usbat2-driver will look more like the 
more complicated isd200-driver.

>>Chris, If you want to take part of the development, please do! I did not 
>>see your name on the list of "stars" on 
>>http://www.lysator.liu.se/~unicorn/hacks/usbat2/, so I guess you did not 
>>participate so far. If you like join us, contact Mike Gibson.
>Well, better wait till I have contributed something useful, or at least
>know a bit what I'm talking about. For now, it's all just a foggy
Same for me. I never wrote a driver before, knew nothing about USB and 
still know nothing (practically) about ATA or SCSI. BTW I believe this 
statement is also valid for the other  usbat2 developers.

>If anyone wants to write a bit to get others up to speed, that would be
>very helpfull. The learning blocks seems to be:
>    * learn about USB, and the protocols on this bus
>    * learn about USB in linux
>    * learn about usb-storage
>    * Read the sniffings, determine what happens, and translate that
>      into a usbat2.c
We are happy that there is also some documentation available from SCM 
which can be useful. It describes the device as well as its instruction 
set. I am afraid we still need the sniffed data badly, because the specs 
of SCM don't give enough information (for me at least).

>If this is all necessary, then I'll certainly not be able to be of any
>use. If anybody can point me at some flaws in my 'things to learn
>first'-list, I'd be very glad.
Most important is "having fun" doing this. If you know how to program in 
C, you're as (un)qualified as we are.


More information about the Usbat2 mailing list