Hi, Mike. Thank you for the reply.
OK, now I see the history.
>> P.S.
>> I also thought that connectionXX:0 is misleading. XX is supposed to be
>> where
>> iscsi session number is put after binding connection and session.
>>
>
> I did not get what you mean here. The XX is the session number.
>
Probably I should have not to say "misleading". Instead, I should have said
it "confused" me.
It seemed to me a bit strange to say like "connectionXX:0" where XX is
session number.
I was wondering why you have to say session number to describe a connection...
But, I now came to a reason by myself. It is said so probably because
it is just useful to indentiy which connection you are talking about
in one-word, and this is useful in logging.
Or, is there any other reasons?
However, I still think it is misleading to say connectionXX:0 before binding
connection and session. In iscsid.c:session_conn_poll(), connectionXX:0 appears
before binding.
log_debug(3, "created new iSCSI session sid %d host "
"no %u", session->id, session->hostno);
snip....
log_debug(3, "created new iSCSI connection "
"%d:%d", session->id, conn->id);
snip....
log_debug(3, "bound iSCSI connection %d:%d to session %d",
session->id, conn->id, session->id);
Does it fit you very natural? Is it only me to worry about it?
2010/1/7, Mike Christie <micha...@cs.wisc.edu>:
> On 01/02/2010 01:56 PM, Yangkook Kim wrote:
>> Hi, Group,
>>
>> I am wondering why we have /sys/class/iscsi_connection for iscsi
>> connection
>> in sysfs filesystem.
>>
>> I understand that the one or more iscsi connection form a single iscsi
>> session
>> and, in this sense, iscsi connection subordinates to iscsi session.
>> Then, it more makes sense if we have iscsi_connection/ under
>> iscsi_session/.
>>
>> Ex. /sys/class/iscsi_session/iscsi_connection/connectionXX:0
>
> Hey,
>
> Sorry for the late reply.
>
>
> We sort of have that. The reason we have
> /sys/class/iscsi_connection and then
> /sys/class/iscsi_session is due to how the kernel APIs work. For them we
> are using transport classes and classes (see the kernel file
> scsi_transport_iscsi.c), and this is just how they get laid out. We
> could have just made the iscsi_connection a struct with a kobject and
> then added that directly under the session, but at the time people did
> not like the idea of messing with kobjects directly.
>
> So if you look in the iscsi_session dir
>
> /sys/class/iscsi_session/session1
> ls
>
> abort_tmo ifacename password tpgt
> data_pdu_in_order immediate_data password_in uevent
> data_seq_in_order initial_r2t power username
> device initiatorname recovery_tmo username_in
> erl lu_reset_tmo state
> fast_abort max_burst_len subsystem
> first_burst_len max_outstanding_r2t targetname
>
>
> there is a device dir/link. When you follow that you see
>
> ls
> [r...@max session1]# cd device/
> [r...@max device]# ls
> connection1:0 iscsi_session power target6:0:0 uevent
>
>
> how the connection is below the session1. So sort of what you would
> expect but there is that device dir/link due to us using the
> classes/transport_classes which use device structs instead f kobjects
> directly.
>
>
>
>
>>
>> Can anybody give me an explanation?
>>
>> Thanks
>> Kim,
>>
>> P.S.
>> I also thought that connectionXX:0 is misleading. XX is supposed to be
>> where
>> iscsi session number is put after binding connection and session.
>>
>
> I did not get what you mean here. The XX is the session number.
>
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@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?hl=en.
