Re: [PATCH] scsi_transport_iscsi.c contexts

[Mike Christie <mikenc@us.ibm.com>]

Mike Christie wrote:
> Nicholas A. Bellinger wrote:
> 
>> On Fri, 2005-04-29 at 14:20 -0700, Mike Christie wrote:
>>
>>>>> The reason all the settings are stuck on the session was becuase we 
>>>>> couldn't
>>>>> come to an agreement on the layout. We wanted to do something like 
>>>>> this:
>>>>>
>>>>> /sys/class/iscsi_session/iscsi_connection
>>>>>
>>>>> or even
>>>>>
>>>>> /sys/class/iscsi_session
>>>>> /sys/class/iscsi_connection
>>>>>
>>>>
>>>>
>>>> I am still thinking on this one.  First and foremost I think that we
>>>> need to get move towards a single class for iSCSI Initiators instead of
>>>> what is currently registered (/sys/class/iscsi_transport
>>>> and /sys/class/iscsi_host).  Let me keep working on this some more 
>>>> and I
>>>> will draft up a prosposal in the near future.  Any futher input is
>>>> welcomed. :-)
>>>>
>>>
>>> get everyone to agree (or force them) on how to set the initiarname 
>>> and alias
>>> and the iscsi_host can be chopped. the iscsi_host is only there 
>>> becuase sfnet
>>> used a /etc file and I think you can set the initiatorname on some HW 
>>> cards
>>> from a BIOS/OF prompt (or you will not have control over it) so if 
>>> they ever
>>> end up on the same box and wanted to konw what each one ended up as 
>>> you could.
>>>
>>
>>
>> Ok, one possible solution is when the iSCSI Template structure gets
>> registered with the iSCSI Transport, the LLD can tell the transport what
>> values are already defined.   I think this point really goes back to
>> previous points about different class attributes need to be dynamicly
>> registered within the iSCSI Stack when certain events occur.
> 
> 
> I am not arguing with that. We sent a patch to break the session
> stuff from the target (sfnet did not need the channel abstraction) and
> from there to add a connection beneath it is a matter of getting hold
> of the correct kobject to stick things under (when you use the
> transport class/container stuff it is not as simple as before though).
> 
> We are also not using sysfs for creation anymore though. Maybe we need
> to discuss that point too. We are using netlinks for this so
> open-iscsi/linux-iscsi/whatever-name-it-is-called-today:) and pyx have some
> confliting points.
> 
> As far as filesystem based creation stuff goes it also seems our sysfs
> masters may prefer configfs for things like software iscsi, dm or bonding
> where userspace is driving the device creation and not the kernel. Do
> the scsi maintainers care about this?
> 

One clarifcation for that last paragraph. I mean configfs for just the
creation part. And sysfs would still be used to export info to userspace.

Or netlink for all or parts or some other fun combo :)