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
