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 :)
We sort of do. The bsg code in scsi_transport_sas to send SMP frames to
expander devices would be an example of non-scsi commands going via a
mechanism other than being encapsulated in SCSI. I don't know if that's
the complete solution in this case, but you could investigate it.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
