> 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 :) > 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. 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. 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. > 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. -Artem _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
