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