On 07/27/2009 01:48 AM, Hannes Reinecke wrote:
> Hi all,
>
> why do we have this call to iscsi_session_chkready() in queuecommand?
>
>       reason = iscsi_session_chkready(cls_session);

It is only now there because I am bad at predicting the future. I 
thought there would be more driver like qla4xxx.

I wanted to export the iscsi state for all iscsi drivers, so I started 
moving the iscsi state from libiscsi to the iscsi class so drivers like 
qla4xxx could use it. It turns out that qla4xxx is the odd driver and 
everyone went the libiscsi route.

I am in the process of now hooking qla4xxx into libiscsi (it will not 
use iscsid for login though).


>       if (reason) {
>               sc->result = reason;
>               goto fault;
>       }
>
>       if (session->state != ISCSI_STATE_LOGGED_IN) {
>               /*
>                * to handle the race between when we set the recovery state
>                * and block the session we requeue here (commands could
>
> Seeing that iscsi_session_chkready() returns '0' when
> session->state == ISCSI_STATE_LOGGED_IN _only_,
> one of the two is rather pointless.
> But as the latter check is far more elaborate than
> the iscsi_session_chkready(), I'd advocate for just removing it.
>

You want the last one right now. It can take a while for the class state 
to get set. iscsi_conn_failure sets the libiscsi state right away when 
the problem is detected. The class state is not set until we call 
iscsi_block_session.

If you wanted to remove the second check, you would want to modify 
iscsi_block_session so that it could be run from soft irq context 
instead of queueing __iscsi_block_session to be run from a work queue. 
So I guess I mean we would want to kill iscsi_block_session and just run 
__iscsi_block_session from iscsi_conn_failure.. I think we can actually 
do this now. We origianlly did not because the driver model device iter 
code used a mutex.

I think we would need to also modify some of the checks for if a block 
is running while we want to unblock or remove a session, because they 
rely on checking of the block_work is running or queued (actually I 
think they flush the entire thread).

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to