On Nov 5, 2007 6:16 AM, Garrett D'Amore <gdamore at sun.com> wrote:
> So, I've been thinking about my sdcard block driver (which, btw, I've
> now gotten to successfully mount a read-only media), and struggling with
> the code for libsmedia (Gnome integration, etc.), fdisk, etc.
>
> I'm gradually coming to the conclusion that I've been going about this
> all wrong, but I'm interested to hear other ideas.
>
> Right now, I have my own driver, which will not readily be reusable, for
> SDcard (and also MMC card) media. I can certainly make this work, as
> my initial code has demonstrated.
>
> 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,
> and userland applications would not be able to easily tell the
> difference between an SDcard inserted in a USB reader or one inserted
> into an SDHCI reader.
>
> 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.)
>
> 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.
>
Garrett,
I think that leveraging existing SCSA framework is a very wise thing to do.
While some may argue that having another layer of translation won't bring
you best performance I think that for the task in hand it is absolutely
appropriate. Some time ago I did a driver like that for some "interesting"
storage controller. Worked very well.
Also having a common SCSA-to-something-else module is something
worth of exploring more. It can be quite useful I think.
--
Regards,
Cyril
