Re: ioctls, etc. (was Re: [PATCH 1/4] sas: add flag for locally attached PHYs)

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Jeff Garzik wrote:
> Luben Tuikov wrote:
>>>>> Examples are DMA boundary and s/g limit, 
>>>>> among others.  When confronted with this, you proposed an 
>>>>> additional hardware information struct which duplicates 
>>>>> Scsi_Host_Template.
>>>>
>>>> I told you -- I have this in the struct asd_ha_struct and it was merely
>>>> a downplay that I didn't include the same thing in struct 
>>>> sas_ha_struct.
>>
>> Here is the commit in question:
>> http://linux.adaptec.com/sas/git/?p=linux-2.6-sas.git;a=commit;h=785747ddc631f7618d728a377346965f7db2256a 
> 
> This effectively illustrates the wrong thing to do:  duplicating 
> information that's already in Scsi_Host_Template.
> 
> Just use Scsi_Host_Template in the LLDD and see where that goes.

Will cmd_per_lun, sg_tablesize, max_sectors, dma_boundary, 
use_clustering ever have to be adjusted specifically for a SAS hardware?

Obviuosly none of this is required _at the moment_. IOW neither the 
introduction of a sas_ha_hw_profile nor a pass-through of 
scsi_host_template down to SAS interconnect drivers is required right 
now. So why do one or the other now? Isn't it a sensible rule to not 
solve problems now which do not exist yet?

(I guess Luben only introduced sas_ha_hw_profile to demonstrate that 
there will never be an absolute requirement for scsi_host_template --- 
in its present form --- to be visible in a SAS transport layer <-> SAS 
interconnect driver interface. And there are certainly more alternatives 
to these two approaches.)
-- 
Stefan Richter
-=====-=-=-= =-=- =-==-
http://arcgraph.de/sr/