>-----Original Message-----
>From: Mike Christie [mailto:[EMAIL PROTECTED]
>
>I was thinking that for scsi commands do we need fc_exch.c to set a
>timeout for the abort? If not then we can just have fc_fcp call some
>other function that does not set the timer for the abort (or just
modify
>the existing function to take an extra argument to indicate the timeout
>and if not set then fc_exch.c would not set one).
>
Yeah this is good idea :-).
As you suggested, I'll change fc_seq_exch_abort() to accept abort
request timeout argument. If any other (non-libfc) fc_fcp.c
implementation wants this timeout then they can also add -FC_EX_TIMEOUT
handling accordingly.
As you described below this will also eliminate special code (checks for
FCP type) in the fc_exch.c and will make fc_exch_timeout() more clean.
Thanks
--Vasu
>The fc_fcp.c layer will always set its own abort - sort of I guess. If
>the abort is sent because the scsi command timed out at the scsi layer
>and the scsi eh is initiating it, then fc_fcp_pkt_abort will set its
own
>timeout.
>
>And if the abort is send because fc_timeout_error is doing the abort,
>then the scsi command timer will eventually timeout and when the scsi
eh
>runs it will see that we sent an abort and it did not complete and will
>then send a lu reset. So in one way or another fc_fcp.c will set a
>timeout for scsi_commands and does not need fc_exch.c to do it. So if
>fc_fcp_error is does not want the -FC_EX_TIMEOUT maybe we should set
>things up so it would not get one for the abort and not have fc_exch.c
>do it for the upper layer. I mean if the upper layer set a timeout it
>wants the -FC_EX_TIMEOUT. If it doers not set the timeout then it does
>not. So that way we would not need any special code in the fc_exch.c
>time out handler code to guess what the upper layer wanted.
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
