Date: Sat, 1 Jan 2000 16:52:24 -0500 (EST)
From: Eric Youngdale <[EMAIL PROTECTED]>
This could be a little more complicated than I originally thought.
The first question is how exactly would people like to use these?
Internally from the driver, or do you also need to get at it from sg as
well?
Internally from the driver, completely.
Here is one usage I once had in mind. Consider a driver which has
full control of the bus transactions, for example MSG phases generate
interrupts and the host adapter is told directly what to do about it
etc.
So think about receiving an ABORT due to a parity error and wanting to
drive the device precisely next into a REQUEST_SENSE or other status
probing command, and absolutely guarentee that no other transactions
go through the host adapter between the ABORT event and the status
query.
In such a case what I would want to do is cook up a REQUEST_SENSE
myself in the driver, and send it off immediately after finishing
the command which has aborted.
Because I have created this command myself, I can demark it as such
and when the result comes in I can look at the sense return and do
things such as:
1) Make synchronous parameters less aggressive.
2) Go to asynchronous data transfers
3) Set a "slow cable mode" or similar for this device if the
cable appears to be very "noisy" (ie. the abort condition
came while even in asynchronous mode)
Do this clear things up for you?
Actually, I know for a fact that higher end SCSI adapters do this
exact sequence in the firmware and transparently to the kernel driver.
So essentially what I'm asking for is a mechanism by which I can do
this by hand in the kernel driver and not have to reimplement command
creation and dispatch logic in a bunch of drivers where this would be
done.
If I were to do anything soonish, I would tend to take a
conservative approach, and not create a permanent device structure, which
would sidestep all of the other issues. It would also imply that you
would be unable to use the thing from sg, of course. The main question is
whether this would be useful or not (it would solve the problem for gdth,
but I don't know what other people have in mind).
As far as I can tell, this would be fine for my intended purposes,
and as you mention allow the GDTH case to be handled as well.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
