I also am going to add two new status codes, B2S_ENOMEM and
B2S_ETIMEDOUT. These are used as you would expect, when a request
cannot complete due to insufficient memory or timing out.
-- Garrett
Garrett D'Amore wrote:
> Cyril Plisko wrote:
>> On Nov 14, 2007 7:46 PM, Garrett D'Amore - sun microsystems
>> <gd78059 at sac.sfbay.sun.com> wrote:
>>
>>
>>> The b2s_target_t structure is a handle to an emulated SCSI disk. It
>>> has the following accessible members:
>>>
>>> uint16_t target_number;
>>> void *target_private;
>>> const char *target_vendor;
>>> const char *target_product;
>>> const char *target_revision;
>>> const char *target_serial;
>>> uint32_t target_flags;
>>> boolean_t (*target_request)(void *, struct b2s_request *);
>>>
>>>
>>
>> Garrett,
>>
>> Provided that this module aims to be generic, how easy will it
>> be to add support for protocol revisions beyond SCSI-2 ?
>>
>
> Its generic for a certain class of application... that is block device
> support. I don't think it will be too difficult to extend to other
> kinds of block oriented mass storage. (I'm already thinking about
> using it for other kinds of flash media, such as xD, etc. I think it
> could be used today for the pcram module as well.)
>
>> I think that single target_request() callback may not be robust
>> enough in case such functionality addition will be required.
>>
>
> I think it would be straight-forward to add other SCSI protocol
> extensions. I assume you're thinking about mode-sense/select, vital
> product data, log sense, and maybe even media serial number requests.
>
> For those cases I think target_request() is extensible enough. The
> reason for this is that the b2s_request_t structure is dynamically
> allocated and thus easily extensible. So it can carry other kinds of
> fields, the same that it carries br_media today. (In fact, br_media
> is already a member of a union. I think this does point out to me one
> thing, which is that I should make sure that the union is the last
> member of the br_request_t.... so I need to move br_flags in front of
> it.)
>
> Is there some other kind of exchange you perceive where you think this
> br_request is insufficient?
>
> -- Garrett
>
