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]

 



Luben Tuikov wrote:
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

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.


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.

Correct. That's why there is resistance to aic94xx's approach of creating a totally new "strict SAM" path, existing in parallel with the traditional SCSI core. You need to evolve the existing code to get there. Such changes are gradual, involving more than one developer, etc.

We don't need one small set of SCSI drivers behaving differently from the vast majority of existing SCSI drivers.

Hear me now, and believe me later: we all largely agree on the points you've raised about legacy crapola in the SCSI core. James, Christoph, myself, and several others disagree with your assertion that the old SCSI core should exist in parallel with your new SCSI core.

We differ on the path, not the goal. As a thought experiment, you could try simply implementing the changes requested, and see where that goes.

	Jeff


-
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