On Tue, 2002-07-23 at 14:57, Rogier Wolff wrote:
> Now it won't be as easy as this. But for instance in my firestream
> driver, you sometimes put a value in a register in the chip, and if
> later on you read it back, you want the chip to have left it
> unmodified, or to have it changed in a predictable way. If the value
> is unexpected, a panic is the right "way out".
The high reliability people take a different view. I actually agree with
them. It isnt about 'oops didnt happen' it is about controlling the
failure case
Suppose your firestream driver reports catacylsmic internal error
status. Their argument is not that you should pretend life is good but
that the driver should log a fault and shut off the chip as best it can.
So you might have a firestream_failed() function which did
Disable master bit
Put board into D3
Wait
Put board into running state
Try to reset and configure it
If this fails shove it in D3 and give up
At this point the high reliability system is servicing the other links
it manages and flashing warning lights to the engineers, rather than
completely down
-
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
|
