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

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

Mike Christie wrote:

> 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().

For bus usage and virtual drivers like this and scsi_debug, would it be 
better to just have a single virtual bus for all virtual drivers to 
share, or should we instead modify the scsi_bus so that it can handle 
ULD and virtual LLD struct device_driver attachments. Today, the 
scsi_bus seems to be used for upper layer drivers becuase they are the 
only ones needing to attach UL struct device_drivers to scsi devices, 
but instead of scsi_debug or iscsi-sfnet implementing its own virtual 
bus the scsi_bus could manage a low level virtual driver's scsi_host 
parent's devices.

Also, with James's patch we have scsi_devices and scsi_targets off the 
scsi_bus, does scsi_host's shost_gendev belong there too? What is the 
purpose of the scsi_bus?


> 
>>  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.
>>
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>