Artem Kachitchkine wrote:
>> struggling with the code for libsmedia (Gnome integration, etc.)
>>
> > , fdisk, etc.
>
> If you have to mess with fdisk and libsmedia(yuck), that's a pretty good
> indication you're on the wrong track :)
>
Yeah. cmlb helps with most of it, but I'd have to create new disk type
identifiers, which means a new libsmedia module, IIUC. :-(
>
>> But I'm wondering if I should take a different approach and produce a
>> SCSA HBA emulation instead. Then I could leverage the SCSA framework,
>>
>
> That would make your life much, much easier.
>
>
>> The problem is that natively, SDcard is *not* SCSI, so I'd have to
>> emulate support for basic SCSI commands: read, write, inquiry, mode
>> sense, and possibly a couple of others. (This is unlikely the 1394 and
>> USB layers, which basically encapsulate SCSI.)
>>
>
> SCSI is very diverse, so many command sets it supports (not just
> storage, but also printers, CPUs, etc). In SCSA, HBA drivers simply
> transport the commands, target drivers being the ones that define
> command set.
I understand that.
> 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. I realize its a PITA to do it,
but I *think* it is probably not too hard. After all, these USB card
readers have to have that code implemented in *firmware*.
> BTW, USB and 1394 SCSI "encapsulation" sounds nice in theory, but
> scsa2usb and scsa1394 have some very gnarly hacks in them. (Just so you
> don't feel singled out). So much so, that some of us were thinking at
> some point about splitting sd into two halves, replacing the bottom half
> just for USB.
>
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.
>
>> So the approach I'm thinking of is basically creating a "simple"
>> framework for raw LBA style access -> SCSI translation. Then I could
>> reuse this layer for other kinds of devices besides SDcard, such as
>> memstick, raw NAND flash devices (if they ever show up in computer
>> systems), etc.
>>
>> I've very little experience with SCSI and SCSA, so this would be a new
>> direction for me. But I think at the end of the day, that it might be
>> the better approach. But I'm interested to hear counter arguments, and
>> if folks experienced with either can point out any flaws in my thinking,
>> I'd be grateful to hear them.
>>
>
> I think to generate any sort of useful advice we'd have to look at the
> SDcard command set.
>
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":
1) read block(s)
2) write block(s)
3) get capacity (in blocks)
4) erase block(s)
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"
operations, and layers a generic SCSI block device target emulation
above them.
There are a few extras, that I'm not planning on supporting (at least
not right away). I don't think any of these can be used with USB
readers, so its probably not a great loss.
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)
Thanks for the input.
-- Garrett
> -Artem
> _______________________________________________
> driver-discuss mailing list
> driver-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
