From: Matthew Wilcox <matthew@wil.cx>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [RFC 1/2] scsi core: alloc_cmnd
Date: Tue, 23 Oct 2007 13:15:27 -0600 [thread overview]
Message-ID: <20071023191526.GS27248@parisc-linux.org> (raw)
In-Reply-To: <471E419C.9020005@panasas.com>
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."
next prev parent reply other threads:[~2007-10-23 19:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-19 18:33 [RFC 1/2] scsi core: alloc_cmnd Matthew Wilcox
2007-10-23 16:49 ` Boaz Harrosh
2007-10-23 17:48 ` Matthew Wilcox
2007-10-23 18:46 ` Boaz Harrosh
2007-10-23 19:15 ` Matthew Wilcox [this message]
2007-10-23 19:49 ` Boaz Harrosh
2007-10-23 19:27 ` Christoph Hellwig
2007-10-23 20:24 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071023191526.GS27248@parisc-linux.org \
--to=matthew@wil.cx \
--cc=bharrosh@panasas.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox