Cyril Plisko wrote:
> Cc: to storage-discuss as well
>
> On Nov 13, 2007 11:47 PM, Garrett D'Amore <[EMAIL PROTECTED]> 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 ?
>
I thought I said I am supporting ANSI X1.131-1994. I.e. SCSI-2. This
is from the era before the SCSI command sets were broken into separate
specifications. Yes, its ancient, but its easier than SCSI-3, and
sufficient to my needs. (Doing SCSI-3 means adding required features
that I didn't bother with, like mode sense, page 80 inquiry data, etc.)
> 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.
>
DTYPE_DIRECT, so 0x00 is correct. I will add that.
> 3. Any provision for supporting other types of SCSI devices ?
> Admittedly in this case it might be more generic than *blk*2scsa.
>
I thought about it, and decided it would be rather pointless. If it
ever happens that a need arises, then maybe it can be changed.
> 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 ?
>
Correct. Each "instance" in the parent emulates a bus, and I figured
supporting multiple targets was sufficient. I couldn't really imagine
any reason to have a hierarchical LUN structure.
> 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 ?
>
Its awkward for drivers to store them that way (especially since they
might be getting them from other places as well! There could be
multiple layers here.) The code to align and truncate, and space pad is
trivial in blk2scsa.
/*
* This copies a string into a target buf, obeying the size limits
* of the target. It does not null terminate, ever.
*/
#define COPYSTR(src, dst) bcopy(src, dst, min(strlen(src), sizeof
(dst)))
Does it, after I start by memset() the structure fields to ' '.
> 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 ?
>
I actually went back and forth on it. I ultimately decided this was
easier. I guess it is a matter of opinion though.
> Nit:
> auto-sense-request should be auto request sense
>
Ah right. Thanks.
I've been figuring out SCSI and SCSA as part of this project, so the
terminology may be confusing me. :-)
-- Garrett
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
