Hi Mike,

We're working now on sort of house cleaning w.r.t the iser transport
code that deals with connections tear-down and resources cleanups.
Examining the iscsi state machine ladder diagram for connection
establishment and login which goes like:

01 transport end-point (create and) connect
02 create session
03 create connection
04 bind iscsi connection to the transport connection
05 set non-negotiated params
06 send/recv login request/response
07 set negotiated params
08 start connection

[etc]

A possible oredering for normal termination could have been something like:

09 stop connection
10 send/recv logout request/response
11 unbind iscsi connection from the transport connection
12 destroy connection
13 destroy session
14 transport end-point disconnect (and destroy)

In reality it's not the case -- there's no unbind primitive and the
actual order is the following:

09 send/recv logout request/response
10 transport end-point disconnect (and destroy)
11 stop connection
12 destroy connection
13 destroy session

Just to make sure, I got it right, correct?

Now, under this design, we consider the transport end-point disconnect
to be interpreted as

10.1 unbind iscsi connection from the transport connection
10.2 disconnect

and this design is OK with us. We just want to make sure that after
issuing the disconnect call, the iscsi layer will not attempt to do
anything with the iscsi connection expcet for stopping/destroying it
or binding it to **new** transport end-point which was
created/connected through the recovery flow.

In this case, the iser entries planted for the below callbacks would
just be direct pointers into libiscsi service routines

stop connection      -  iscsi_conn_stop()
destroy connection  - iscsi_conn_teardown()
destroy session       - new function iscsi_session_destroy (*)

(*) today we use iscsi_session_teardown, and we need to add there
calls to iscsi_host_remove () and iscsi_host_free()

So how all this sounds? I tend to think that in the past stop_conn
used to be before sending the logout request, is that true?

Or.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to