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

Luben Tuikov
2005-10-21T22:15:14Z

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
--