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

[Jeff Garzik <jgarzik@pobox.com>]

Luben Tuikov wrote:
> On 10/21/05 17:12, 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.
>
>
> > 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.

The correct answer is NOT to duplicate information between 
Scsi_Host_Template and Lubens_Hardware_Struct.


> > driver is implemented.  The host template is in the low level driver, 
> > while most of the code is common code, implemented elsewhere.
>
>
> libata isn't without architectural problems.  What strikes me is
> that you think that libata-scsi is SATL.

The only things that matter are (a) what the code is now, and (b) what 
changes are needed to get where we need to be.

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.


> You are so much better off renaming it to satl.c and given

Naming is completely irrelevant.  Just modify the code.

	Jeff


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