On 10/21/05 17:41, Jeff Garzik wrote: >>>I already described why. 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 >>>Solution? Just use Scsi_Host_Template. Take a look at how each libata >> >> >>No, this is the solution which would turn everything upside down. >>The easiest and smallest solution is to just include this tiny struct >>and end this. It would have 0 impact on code. In fact I'll >>implement it now and push it to the git tree. ;-) >> >>The host template _mixes_ hw, scsi core, and protocol knowlege into >>one ugly blob. > > > True. > > If you do not like the current situation, evolve the SCSI core (and all > drivers) to where you think they should be. While the architecture in my mind is clear, I cannot do this myself (and for all drivers). Such a change would be gradual, involving more than one developer, for more than one (new) driver, etc. First we need SDI to make everyone happy. This way HP/LSI/Adaptec can move quickest to the customers with minimal pain to the customers and to the companies which would have to change software (minimal change). > Thus, regardless of whether or not libata-scsi meets the needs of > SAS+SATA hardware, libata-scsi is where all SCSI<->ATA translation > should occur. If you are dissatisfied, evolve the code to where it > needs to be. Ok. > Naming is completely irrelevant. Just modify the code. Ok. Luben -- http://linux.adaptec.com/sas/ http://www.adaptec.com/sas/ - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
