On Nov 5, 2007 6:16 AM, Garrett D'Amore <[EMAIL PROTECTED]> 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
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss

Reply via email to