>> The main benefit of going the SCSA way is leveraging the 
>> sd(7D) driver, which is really what userland apps care about. You could 
>> implement sd's APIs in a non-SCSA driver, but that's a lot of work.
> 
> I'm thinking not of sd's APIs, but really implementing a SCSI "target" 
> (or emulation) that supports the SCSI block read, write, inquiry, 
> start/stop, and mode sense commands.

Your end goal is to reuse storage apps in userland without modification. 
That means sd APIs. sd is _the_ SCSI "target" in Solaris, but you cannot 
leverage it unless yo implement a SCSI "host" underneath it. dkio(7I), 
uscsi, etc.

> Wow.  That's surprising.  I did see some ugly scsa2usb hacks for devices 
> that didn't implement all the various SCSI commands.  Possibly I could 
> leverage some of that for what I was thinking of.

Yeah, some techniques from scsa2usb will be useful for you.

> SDcard for memory devices is *relatively* simple (as long as we ignore a 
> few esoteric parts of the spec that won't work with USB readers 
> either).  The commands fall into a few simple "classes":

Well, there's no simple answer, you will have to do some homework. Take 
the command set that sd expects (a random collection of SBC-2, MMC, ... 
- ugh) and try to map it to the SDcard command set. The hard part is how 
to deal with commands that don't have an sd counterpart. For some of 
them you'd be able to simply fake sense data (like illegal command), but 
I doubt you'd get away without modifying sd.

>     1) read block(s)
>     2) write block(s)
>     3) get capacity (in blocks)

Maps to SCMD_READ/WRITE/READ_CAPACITY

>     4) erase block(s)

That could be a problem.

>     5) identify card (related to bus performance criteria... e.g. 
> timings, etc.  the sdcard "target" doesn't use this info, but the nexus 
> driver needs it to program clocks, etc.)
>     6) identify card (related to vendor, model, serial number, etc.)
> Given this, I can imagine a generic layer that takes the above "generic" 

Perhaps add solid state memory specific ioctls to sd?

>     1) lock/unlock card (with a password)
>     2) set/clear write protection on card (some cards have "region" 
> level support for this, but the latest spec dropped that)
>     3) "security" commands, related to DRM (I'm not going to support 
> these, so DRM content will not be supported)

I think ZIP/JAZ diskettes had similar features that Solaris already 
supports.

-Artem

Reply via email to