Subject: Re: more new scsi midlayer questions
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
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.

Fair enough.


> 
> > 
> > > 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
to scsipi_channel_thaw:

        /*      
         * 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)
                scsipi_run_queue(chan);


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
	 * function).
         */             


-matt