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]

Date:	Tue, 12 Feb 2008 16:53:50 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
cc:	James.Bottomley@...senPartnership.com, jeff@...zik.org,
	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, 12 Feb 2008, David Miller wrote:

> From: Linus Torvalds <torvalds@...ux-foundation.org>
> Date: Tue, 12 Feb 2008 10:59:00 -0800 (PST)
> 
> > That sure as hell would put the pain on API changes solidly where it
> > belongs.
> 
> If a person does a driver API change and does all the work to sweep
> the entire tree updating all the drivers, doesn't it penalize that
> person a bit much to stick a new driver in front of that work?

If that API change doesn't conflict with the work that hundreds of other 
people do, it's obviously not a problem whichever way it goes.

And if the API change *does* cause conflicts, then yes, the onus of fixing 
those conflicts (again) goes to the person who changed the API. Everybody 
else did everything right.

> People write code on top of infrastructure, both new and old, not the
> other way around.  At least to me, that seems how the merging ought to
> work too.

You think that infrastructure is more important than outlying code. But 
you do that only because you write the infrastructure, not because you 
have any logical reason to think so.

The fact is, that "outlying code" is where we have all the bulk of the 
code, and it's also where we have all those developers who aren't on the 
"inside track". So we should help the outliers, not the core code. 

And very fundamentally, API changes are to be discouraged. If we make them 
harder to do and make people think twice (and occasionally say "not worth 
it"), that sounds like a damn good thing to me.

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