Grant Zhang wrote:
> Given the current name convention, does it make more sense to name
> this as scsa2blk? (just to mimic scsa2usb, scsa1394)
Heh. I noticed that yesterday as well when I was writing the PSARC
20-questions file. I sort of think the other two are named backwards.
:-) But I guess it is really just a matter of perspective... scsa2sb
and scsa1394 live in the usb and 1394 directories. blk2scsa lives in
the scsi directory.
Its a pain in the butt to change it (all the identifiers everywhere
change), but if people feel strongly enough about changing the name,
I'll do so. (I had decided yesterday not to do this unless someone
complained.)
-- Garrett
>
> Grant
>
> 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 ?
>>
>> 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
>>
>>
>>
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
