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

[Mike Christie <michaelc@cs.wisc.edu>]

Mike Christie wrote:
> Matthew Wilcox wrote:
> 
>> On Mon, Sep 06, 2004 at 04:32:51PM +0200, Christoph Hellwig wrote:
>>
>>> On Wed, Sep 01, 2004 at 11:20:42AM -0500, AJ Lewis wrote:
>>>
>>>> Do we want all these attributes in the scsi_host class, or should we 
>>>> put them
>>>> in the iscsi devices directory?  So in 
>>>> /sys/bus/iscsi-sfnet/devices/iscsi1 -
>>
>>
>>
>> Woah, woah, woah.  What's this "iscsi-sfnet" directory in sysfs?  That's
>> just wrong. 
> 
> 
> It is only a pseudo bus for the driver from Christoph's suggestion,
> that's just to make probing and removing of the driver's devices easier (it
> looks like a normal scsi driver now).

Oh yeah, just to add so you do not have to read through the entire thread.
As you know struct device_driver's need a bus to attach devices through,
so a scsi_host could have a pci_driver, parent pci_dev and the pci bus
for this purpose. Since this driver is software the iscsi-sfnet bus and
iscsi-sfnet driver are a virtual bus and driver to emulate what the pci
bus does for normal drivers.

For my comment where I state we look like a normal scsi driver I just mean
in our struct device_driver->probe we do the scsi_alloc/add_host() and in our
struct device_driver-?reomve we do the scsi_remove/put_host().


>  No way is that crap going into the kernel.  We have to have
> 
>> *one* iscsi infrastructure, not a dozen.
>>
> 
> Don't worry, there is no way we are going to put transport, scsi or
> anything like that there. This driver will use the scsi-ml infrastucture
> for sysfs and this includes using the transport classes. I think this 
> comment
> from AJ, was just in error when he was unaware of scsi-ml's transport 
> classes.
>