On Mon, May 21, 2001 at 08:21:41AM -0700, Matthew Jacob wrote:
> On Mon, 21 May 2001, Manuel Bouyer wrote:
> 
> > On Sat, May 19, 2001 at 10:28:16PM -0700, Matthew Jacob wrote:
> > > 
> > > 
> > > scsipi_run_queue is private.
> > > 
> > > The only function available for the HBA to get queues restarted is
> > > scsipi_channel_timed_thaw- but this forces you to call from a softcall
> > > stack (interrupt stack). 
> > > 
> > > Now that we can use threads to our heart's content, wouldn't it be nice to be
> > > able to simply call scsipi_run_queue directly?
> > 
> > I don't think you should call scsipi_run_queue() directly. If you want to
> > restart the queue it's because it has been stopped, so you need to thaw it.
> > Maybe we should expose scsipi_channel_taw(), but I think scsipi_run_queue()
> > should be keep private.
> 
> I think you're missing the point. The only mechanism with which
> scsipi_run_queue can be called now after a thaw is via the indirect softcall
> mechanism in scsipi_channel_thaw (which is exposed). I don't care whether
> scsipi_run_queue itself is private. I *do* care that you can't restart except
> via a softcall. That's just plain wrong when you've already got a per-HBA
> thread.

This is why I propose to make scsipi_channel_thaw public, this once can be
called from your thread. But I don't think we should allow HBA drivers to
bypass the freeze/thaw mechanism; this will break if we want to change the
internals of scsipi.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--