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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux