Subject: Re: more new scsi midlayer questions
To: Manuel Bouyer <firstname.lastname@example.org>
From: Matthew Jacob <email@example.com>
Date: 05/25/2001 11:43:07
On Thu, 24 May 2001, Manuel Bouyer wrote:
> On Wed, May 23, 2001 at 11:07:43AM -0700, Matthew Jacob wrote:
> > [...]
> > > Also I think that the commit you did about negative freeze count should go
> > > away. When something freeze a channel, the same thing should thaw it, with
> > > the same count.
> > I don't agree. Theoretically, things should be paired. However, in case of
> > mistakes, I still prefer my system to run.
> At last a diag should be printed. If this happens this means the queue could
> run before before everyone wants it to run, and this has to be fixed.
> > > For example, in your case you want to freeze the channel only one time, but
> > > from different places. So you just don't want to freeze a channel again if
> > > it's already frozen by the HBA driver. Keep a flag in the HBA driver, test
> > > it to know if it's already frozen. This way the freeze count of the HBA
> > > driver will always be 0 or 1, and you need to thaw it only with a count of 1.
> > Well, I don't much agree with all of this. It's not very practial, IMO. If you
> > have to keep a flag or a count in the HBA driver, you might as well queue in
> > the HBA driver.
> It's much easier to set/clear a flag, than to manage a queue !
But if you have to keep track....
D'ya mind if I change the message here- you added the following
* Kick the channel's queue here. Note, we may be running in
* interrupt context (softclock or HBA's interrupt), so the adapter
* driver had better not sleep.
if (chan->chan_qfreeze == 0)
The whole point of a lot of this exercise is to be *able* to allow
scspi_run_queue to be called from process context. How about:
* Kick the channel's queue here. Note, we may be running in interrupt
* context (softclock or HBA's interrupt), so the adapter driver had
* better not sleep (unless it's the adapter itself that called this