[dm-devel] Re: [PATCH 3/9] scsi_dh: scsi handling of REQ_LB_OP_TRANSITION

[Chandra Seetharaman <sekharan us ibm com>]

On Fri, 2008-02-01 at 14:00 -0600, Mike Christie wrote:
> Chandra Seetharaman wrote:
> > @@ -1445,9 +1479,24 @@ static void scsi_kill_request(struct req
> >  static void scsi_softirq_done(struct request *rq)
> >  {
> >  	struct scsi_cmnd *cmd = rq->completion_data;
> > -	unsigned long wait_for = (cmd->allowed + 1) * cmd->timeout_per_command;
> >  	int disposition;
> > +	struct request_queue *q;
> > +	unsigned long wait_for, flags;
> >  
> > +	if (blk_linux_request(rq)) {
> > +		q = rq->q;
> > +		spin_lock_irqsave(q->queue_lock, flags);
> > +		/*
> > +		 * we always return 1 and the caller should
> > +		 * check rq->errors for the complete status
> > +		 */
> > +		end_that_request_last(rq, 1);
> > +		spin_unlock_irqrestore(q->queue_lock, flags);
> > +		return;
> > +	}
> > +
> > +
> > +	wait_for = (cmd->allowed + 1) * cmd->timeout_per_command;
> >  	INIT_LIST_HEAD(&cmd->eh_entry);
> >  
> .....
> 
> > +
> >  /*
> >   * Function:    scsi_request_fn()
> >   *
> > @@ -1519,7 +1612,23 @@ static void scsi_request_fn(struct reque
> >  		 * accept it.
> >  		 */
> >  		req = elv_next_request(q);
> > -		if (!req || !scsi_dev_queue_ready(q, sdev))
> > +		if (!req)
> > +			break;
> > +
> > +		/*
> > +		 * We do not account for linux blk req in the device
> > +		 * or host busy accounting because it is not necessarily
> > +		 * a scsi command that is sent to some object. The lower
> > +		 * level can translate it into a request/scsi_cmnd, if
> > +		 * necessary, and then queue that up using REQ_TYPE_BLOCK_PC.
> > +		 */
> > +		if (blk_linux_request(req)) {
> > +			blkdev_dequeue_request(req);
> > +			scsi_execute_blk_linux_cmd(req);
> > +			continue;
> > +		}
> > +
> > +		if (!scsi_dev_queue_ready(q, sdev))
> >  			break;
> 
> I think these two pieces are one of the reasons I have not pushed the 
> patches. I thought the completion and execution pieces here are a little 
> ugly and seem to just wedge themselves in where they want to be.
> 
> Is there any way to make the insertion of non-scsi commands more common? 
> Do we have the code for being able to send requests directly to 
> something like a fc rport done? Could we maybe inject these special 
> commands to the hw handler using something similar to how bsg would send 
> non scsi commands to weird objects (objects like rport, sessions, and 
> not devices we traditionally associated with queues like scsi_devices). 
> Just a thought with no code :) that is why the ugly code existed still :)

Can't it be done with this code itself ?

If the underlying functionality is going to be provided by the hardware
handler, then can't we add additional commands (like transition) when we
need them ?

Or am I missing something ?

-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan us ibm com   |      .......you may get it.
----------------------------------------------------------------------