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

[David Lang <david.lang@digitalinsight.com>]

On Sat, 22 Oct 2005, Stefan Richter wrote:

> Christoph Hellwig wrote:
> > On Sat, Oct 22, 2005 at 12:42:27PM +0200, Stefan Richter wrote:
> > > 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),
> >
> > No way.  Doing things from scatch is a really bad idea.  See how far we 
> > came
> > with Linux 2.6 scsi vs 2.4 scsi without throwing everything away and break 
> > the
> > world.  Please submit changes to fix _one_ thing at a time and fix all 
> > users.
> > Repeat until done or you don't care anymore.
>
> I agree with you. Alas my wording was misunderstandable und obviously carried 
> a wrong tone.
>
> I did not say "replace the core" in step 1. Also, the breakage which I refer 
> to in step 1 would have to be immediately corrected in step 2 (although not 
> for the whole subsystem at once, to allow for a fast cycle of validation of 
> what happened in step 1). Furthermore I specifically said that most steps may 
> (let me add: and should) overlap.

Stefan,
  we are supposed to be on a 2-month release cycle, with all major changes 
going in in the first two weeks of that cycle. This timeframe doesn't 
leave you any noticable time to implement your steps seperatly (and zero 
testing between them). as a result, in practice your proposal amounts to a 
big-bang approach, and/or results in releases that are known-broken.

and while you suggest putting this in -mm, remember that the -mm kernel 
needs to be useable so that people can test it, and it is on the same 
schedule as the main kernel so again you can't have known-broken things 
(of this scale) there either.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
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/