Message-Id: <1202843829.3137.111.camel@localhost.localdomain>
Date:	Tue, 12 Feb 2008 13:17:09 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
	arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, 2008-02-12 at 10:48 -0800, Linus Torvalds wrote:
> But you're all ignoring my fundamental objection: you're talking as if 
> cross-tree fundamental API changes should be the "norm", and that we 
> should try to solve the workflow issues that stem from that. And I'm 
> saying that I think we should try to FIX the issue, and make sure that 
> it simply *isn't* the norm.

OK, I'll address it then (or try to).  Just don't eat me please ... I'm
only a small and timid storage maintainer ...

> In other words, I'm perfectly happy to be an a*hole and tell people that I 
> simply won't merge things that cause undue API churn at all, and that were 
> not thought out sufficiently.
> 
> We've had too many issues like that (SG chaining, iommu, driver core, not 
> to mention the upheavals in x86) lately, but realistically, which 
> subsystem remains a problem for the future? And maybe the correct thing to 
> do is to just say "enough!".

I can sort of agree, but I don't think you can say enough == no more API
changes.  There's the request_irq argument removal patch floating around
somewhere for instance ...but as someone said "Every rule always has an
exception".

I think what's really needed is a balance where it's painful (on the
originator) to make an API change.  Part of what -mc or -next trees can
do is to make that pain visible early (and often).

> I'm perfectly happy being hardnosed and saying "nope, that's crap, it 
> doesn't matter if the code is slightly better if you cause those kinds of 
> issues".

OK, so you can supply the pain as well.

> The thing is, sometimes the answer really *is* "Don't do that then!". If 
> our model becomes bogged up by cross-subsystem serialization issues, that 
> means that we (a) spend too much time handling the fall-out from that and 
> (b) too little time just refining the details.

I think this is exaggerated.  By the end of the -rc cycle for 2.6.24 I
had six merge fixup patches because of trivial cross subsystem API
changes and two dropped trees because of intractable problems (and they
were notified and later fixed themselves up).  Given that I was
including about 50 git trees and 4 quilt ones, that's not too bad,
Especially as we had all the API churn you mentioned.

> And quite frankly, while "good core architecture" matters a lot, in the 
> end, "getting all the boring small things right" matters even more! Big 
> architectural churn that cleans up and fixes the "big issues" is totally 
> anti-productive if it means that we don't look at the boring small detail 
> stuff.

I agree with this too.  When I introduce an API, I usually try to make
sure it will last the test of time ... the trouble is, I'm not always
omniscient.

So the point, I think we've reached is that:

     1. we want to try to enforce good design for APIs to try to ensure
        they're as future proof as foreseeable.
     2. We have to recognise that 1. is impossible in practice and
        provide a mechanism for correcting APIs

So, I think our current system is good in that it enforces pain on
people who change APIs.  However, perhaps we are missing the bit where
we reflect longer before introducing APIs in the first place. (hey,
better reviewing ... I've heard that one before ...)

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists