Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2

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

James Bottomley wrote:

> On Tue, 2004-09-07 at 17:37, Mike Christie wrote:
> 
>>Ok. If the new magic iscsi transport specific target code handles target 
>>data like the scsi_host does for hostdata then would it be better to put 
>>our session struct in the target data? I think this also simplifies 
>>refcounting. Most session stuff makes sense hanging off the target so 
>>this might be easier, right?
> 
> 
> Possibly, but only if the way its handled would be the same on all iscsi
> initiator drivers.  Otherwise, if it's specific to the driver
> implementation, it would be in hostdata. 

Yes, ok. That is what I am striving for. By us hanging things like 
target name on the target instead of on the scsi device or scsi host 
will help us conform to other HW iscsi drivers.

  Regardless, you'd still have
> one host per one of these entities.

One host per I_T nexus/session? But I thought the only reason against 
using a single host for all nexii (ignoring the port/channel 
discussion), was that the driver would need its own refcounting.

If the target has some place for driver target data (with the common 
iscsi code going in the appropriate transport class stucts) couldn't we 
just do sometihng similar to how a scsi_device has the hostdata pointers 
and drivers seem to assume when slave_destroy is called they can just 
free what was allocated in slave_alloc. And when the driver does its 
final scsi_host_put it assumes the hostdata will get freed when all the 
handles are released. If the midlayer could provide any similar lifetime 
management functionality for targets the iscsi driver would not need any 
private structures that are refcounted internally since everything could 
fall under the host, device, or target's managemnet.

> The transport class is to abstract out common code from multiple
> drivers, so what goes in there must genuinely be common.  Even if you
> put the common session data in the target, you probably still end up
> having driver specific data in the host.


> James
> 
> 
>