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
--
Regards,
Cyril
