On Tue, Oct 23, 2007 at 08:46:52PM +0200, Boaz Harrosh wrote:
> > We could also add an alloc_bidi_cmnd/destroy_bidi_cmnd to the shost
> > template. Presumably most commands won't be bidi for any given host,
> > so it'd be a waste of space to allocate them for all commands.
>
> Well no one really knows. The OSD scsi devices I use are bidi only commands
> (OK not only, 99%). The rest are not yet defined. (Like raid arrays that do
> write-return-XOR)
What's the usage scenario though? Do we envisage one scsi_host being
dedicated to OSD, or do we envisage OSDs being one component on a FC
network? I suspect the latter, which leads me to want to do something
like ...
struct qla_cmnd {
char *sp;
unsigned int compl_status;
unsigned int resid_len;
unsigned int scsi_status;
unsigned int actual_snslen;
unsigned int entry_status;
}
struct qla_bidi_cmnd {
struct bidi_cmnd;
struct qla_cmnd;
}
struct qla_cmnd {
struct scsi_cmnd;
struct qla_cmnd;
}
But then this requires us to have a bidi_queue_command. That might not
be such a bad idea anyway ...
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
