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

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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

I am not familiar with most parts of the SCSI subsystem. However from 
what I understood, some existing concepts in the core need to be removed 
from SCSI core entirely, others need to be cleaned up WRT what they mean 
and how they represent it. It seems to me that a practical path to go 
would be:

A. Post mock-ups and pseudo code about how to change the core, discuss.
B. Set up a scsi-cleanup tree. In this tree,
     1. renovate the core (thereby break all command set drivers and
        all transport subsystems),
     2. update ~2 command set drivers and ~2 transport subsystems
     3. validate the renovated core,
     4. fix the conceptual errors of the renovated core (as well as
        first few discovered bugs in the implementation),
     5. update all other command set drivers,
     6. update all transport subsystems where resources to do so are
        available,
     7. test all command set drivers as far as hardware is accessible,
     8. test the updated transport subsystems as far as hardware is
        accessible,
     9. fix prominent bugs.
C. In mainline,
     i. mark all drivers which cannot be updated in the mid term as
        scheduled for temporary feature removal (i.e. they will be
        broken for an undetermined period),
    ii. mark all drivers which have been updated in scsi-cleanup tree,
        but were not thoroughly tested, as scheduled for temporary
        feature regression (i.e. they will be experimental for an
        undetermined period).
D. Push scsi-cleanup tree to -mm and shake out bugs.
E. Push to mainline.
F. Fix remaining drivers as time goes by, remove drivers which remain
   broken for too long.

Most steps may overlap, some steps may repeat. Step A is fortunately 
already going on for quite some time.

Step 1.-4. could involve much dispute, thus taking much more time than 
technically necessary -or- (and that would be less fortunate) being 
dragged out into later stages when a conceptually stabilized core is 
desirable. Much of that may be prevented in step A.

I doubt that the desired cleanup of the SCSI core could be done 
on-the-go, i.e. without temporary breakage of larger parts of the 
subsystem (out of mainline). But then again, I don't know much of the 
subsystem, so what am I talking about here?

Also, long-term breakage of smaller parts of the SCSI subsystem in 
mainline is to be expected; breakage which is to be announced and scheduled.
--
Stefan Richter
-=====-=-=-= =-=- =-==-
http://arcgraph.de/sr/
-
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/