Garrett, A couple additional questions:
I can imagine a flash device not supporting multiple outstanding commands (i.e. tagged command queue). Is there any easy way to indicate this? Do flash devices typically have a GUID? If so, would it make sense to pass that back as inquiry page 83 data so SD can make a devid from it, rather than fabricating it? Aaron Cyril Plisko wrote: > Cc: to storage-discuss as well > > On Nov 13, 2007 11:47 PM, Garrett D'Amore <gdamore at sun.com> wrote: > >> I've posted a draft functional specification for blk2scsa (this is my >> generic block device to SCSA disk emulation layer); >> >> http://opensolaris.org/os/project/sdcard-drivers/blk2scsa-spec/ >> >> Feedback appreciated. I still hope to get this started as a PSARC case >> *really* soon. >> >> > > Garrett, > > nice piece. > > General questions: > > 1. Since you are talking about block device you are probably emulating > some version of SBC command set. Can you provide more info on exact > revisions of SPC, SBC (and others if any) this module will support ? > > 2. What Peripheral Device Type is emulated by this module. > Again since you are talking about block device, I assume it is 00h, > but there are other options. > > 3. Any provision for supporting other types of SCSI devices ? > Admittedly in this case it might be more generic than *blk*2scsa. > > Specific questions: > > 1. typedef struct b2s_target b2s_target_t; > > The b2s_target_t structure is a handle to an emulated SCSI disk. It > has the following accessible members: > > uint16_t target_number; > > No hierarchical LUN support, right ? > > const char *target_vendor; > const char *target_product; > const char *target_revision; > const char *target_serial; > > In SCSI world these strings are of fixed size and left-aligned, space > padded. Isn't it better to store them in ready to consume form, rather > than doing the manipulation in the blk2scsa module ? > > boolean_t (*target_request)(void *, struct b2s_request *); > > I would imagine that registering a block of ops entry points > instead of single "swiss army knife" callback can be more > flexible in the future. What do you think ? > > Nit: > auto-sense-request should be auto request sense > > >
