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

Stefan Richter
2005-10-22T10:42:27Z

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