linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080215011145.GA5934@elte.hu>
Date:	Fri, 15 Feb 2008 02:11:45 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Russell King <rmk+lkml@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Arjan van de Ven <arjan@...radead.org>,
	Greg KH <greg@...ah.com>, LKML <linux-kernel@...r.kernel.org>,
	linux-next@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: Announce: Linux-next (Or Andrew's dream  :-))

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Thu, 14 Feb 2008, Stephen Rothwell wrote:
> > 
> > Originally, I assumed the stable branch would be for our "usual" API 
> > changes, but it appears we are not having any more of those. :-)
> 
> It's not that we should _never_ have them, it's that they shouldn't be 
> "business as usual".
> 
> I'm happy with them being a "a couple of times a year". I'm not happy 
> with them being "once or twice for every release cycle". That's the 
> big deal for me.

very much agreed. I've yet to see a _single_ wide-scale API change that 
broke stuff left and right where that breakage was technically 
justified. I have not seen a single one.

All those cases were just plain old botched attempts. Either someone can 
do a large-scale API change like the irq_regs() cleanups with near-zero 
breakages, or someone cannot. In the latter case, gradual introduction 
and trickling it through subsystem trees is a _must_.

and if it's _hard_ to do a particular large-scale change, then i think 
the right answer is to _not do it_ in a large-scale way, but do it 
gradually.

I claim that there's just not a single valid case of doing wide-scale 
changes atomically and departing from the current to-be-stabilized 
kernel tree materially. _Every_ large-scale API change can be done in a 
staged way, with each subsystem adopting to the change at their own 
pace, it just has to be planned well and tested well enough and has to 
be executed persistently. And the moment we trickle things through 
subsystem trees, there's no integration pain, as subsystem trees are 
largely disjunct anyway.

i also fear that having an API-changes-only tree will dillute our 
testing effort of the current to-be-stabilized upstream tree, as it 
materially disrupts the flow of patches. Most maintainers should 
concentrate on stabilizing current -git with only one serial queue of 
fixes and enhancements ontop of that tree. I dont see how having a 
second queue would help - it clearly splits attention.

widescale API changes should be discouraged, and forcing them through 
the harder, "gradual, per subsystem" route is _exactly_ such a strong 
force that discourages people from doing them.

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