Aaron Dailey wrote:
> 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?
I support untagged queueing right now. There is no support in the
framework at present for tagged queueing.
Untagged queuing can support multiple outstanding commands.
>
> 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?
The SDcard devices I'm dealing with have a unique ID, but it is
fabricated from an entirely different namespace. If there is a way to
qualify the ID then that would work. Note that these devices generally
do not have page 83 inquiry data when installed in a USB card reader.
- Garrett
>
> 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
>>
>>
>>
>
