Re: [PATCH] Snoop SET FEATURES - WRITE CACHE ENABLE/DISABLE command

[Jeff Garzik <jeff@garzik.org>]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Jeff Garzik wrote:
>>>> 4) Using [__]scsi_add_device() is a regression from using 
>>>> scsi_scan_target()
>>>
>>> I think it's taken from the hotplug patch 
>>> store-attached-SCSI-device[1].  Using [__]scsi_add_device() seems to 
>>> be the only way to reliably obtain the attached sdev.
>>
>>
>> We want to continue to use scsi_scan_target(), because that's the 
>> preferred model.  In SCSI-land, the target is what receives RPC calls 
>> (ATA commands, for us), which are then dispatched internally to one of 
>> $N logical units (LU) according to the logical unit number (LUN).
>>
>> In libata, of course, there is only one logical unit attached to the 
>> target, LUN 0.
>>
>> Regardless, using [__]scsi_add_device() is a regression, because 
>> libata handles the transport layer completely -- and importantly -- 
>> handles all addressing.  scsi_add_device() is specifically for 
>> H/C/I/L, i.e. SPI (parallel SCSI) addressing.
>>
>> Eventually SCSI will reach a point where HCIL is not the only 
>> addressing method.  SAS disks, for example, are addressed via a LUN's 
>> WWN.  SCSI fibre channel addresses LUNs via WWN as well.  Once SCSI 
>> core does not exclusively use HCIL addressing, libata will reap the 
>> benefits of using the proper scsi_target model.
> 
> I fully agree with everything you said, but we're faced with a real 
> problem here.  libata needs to know the current attached sdev for 
> hotplug and rescan; however, there's no way to determine the current 
> sdev after it's already added.

[looks at the core code again]  That's not the problem.  The real 
problem is that scsi_target hotplug infrastructure is non-existent. 
scsi_transport_fc gives a hint as to how nasty it would be to add such 
code, too.

So, life sucks.  Oh well.  Your solution is therefore the best, under 
present circumstances.  ACK use of [__]scsi_add_device().

	Jeff