![]() | ||||||||||
Messages in this thread |
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-10-22 07:32 [from the cache] ©2003-2008 | ||||||||||