From: Patrick Mansfield <patmans@us.ibm.com>
To: Douglas Gilbert <dougg@torque.net>,
Andre Hedrick <andre@pyxtechnologies.com>
Cc: "J. E. J. Bottomley" <James.Bottomley@SteelEye.com>,
Linus Torvalds <torvalds@transmeta.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: linux-2.4.18-modified-scsi-h.patch
Date: Tue, 19 Nov 2002 10:40:04 -0800 [thread overview]
Message-ID: <20021119104004.A21438@eng2.beaverton.ibm.com> (raw)
In-Reply-To: <3DDA0E63.9050307@torque.net>; from dougg@torque.net on Tue, Nov 19, 2002 at 09:11:47PM +1100
On Tue, Nov 19, 2002 at 09:11:47PM +1100, Douglas Gilbert wrote:
> Andre Hedrick wrote:
> > Greetings Doug et al.
> >
> > Please consider the addition of this simple void ptr to the scsi_request
> > struct. The addition of this simple void pointer allows one to map any
> > and all request execution caller the facility to search for a specific
> > operation without having to run in circles. Hunting for these details
> > over the global device list of all HBA's is silly and one of the key
> > reasons why there error recovery path is so painful.
> >
> >
> > Scsi_Request *req = sc_cmd->sc_request;
> > blah_blah_t *trace = NULL;
> >
> > trace = (blah_blah_t *)req->trace_ptr;
> >
> >
> > Therefore the specific transport invoking operations via the midlayer will
> > have the ablity to track and trace any operation.
>
> Andre,
> No need to convince me: I have already put a similar pointer
> in that structure in lk 2.5 (for either sd, st, sr or sg to use).
> In sg case's it saved some ugly looping in (what was formerly
> called) the bottom half handler. Sounds like your motivation is
> similar.
>
> Doug Gilbert
So we should name it the same in 2.4 as in 2.5: upper_private_data, not
trace_ptr (thought it should really have been sr_upper_private_data,
like all the other fields in scsi_request).
I don't see why we need the #define, or is that another patch?
-- Patrick Mansfield
next prev parent reply other threads:[~2002-11-19 18:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20021118171446.A28459@eng2.beaverton.ibm.com>
2002-11-19 6:16 ` linux-2.4.18-modified-scsi-h.patch Andre Hedrick
2002-11-19 6:28 ` linux-2.4.18-modified-scsi-h.patch Jeff Garzik
2002-11-19 6:42 ` linux-2.4.18-modified-scsi-h.patch Andre Hedrick
2002-11-19 10:11 ` linux-2.4.18-modified-scsi-h.patch Douglas Gilbert
2002-11-19 12:16 ` linux-2.4.18-modified-scsi-h.patch Andre Hedrick
2002-11-19 18:40 ` Patrick Mansfield [this message]
2002-11-19 18:47 ` linux-2.4.18-modified-scsi-h.patch Jeff Garzik
2002-11-19 18:50 ` linux-2.4.18-modified-scsi-h.patch Andre Hedrick
2002-11-19 18:48 ` linux-2.4.18-modified-scsi-h.patch Andre Hedrick
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=20021119104004.A21438@eng2.beaverton.ibm.com \
--to=patmans@us.ibm.com \
--cc=James.Bottomley@SteelEye.com \
--cc=andre@pyxtechnologies.com \
--cc=dougg@torque.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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
all inboxes | Powered by JetHome®