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: <alpine.LFD.1.00.0802121133210.2920@woody.linux-foundation.org>
Date:	Tue, 12 Feb 2008 11:55:45 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <greg@...ah.com>
cc:	Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
	arjan@...radead.org, 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, Greg KH wrote:
> 
> > That's the point.
> 
> Not it isn't.  To quote you a number of years ago:
> 	"Linux is evolution, not intelligent design"

Umm. Have you read a lot of books on evolution?

It doesn't sound like you have.

The fact is, evolution often does odd (and "suboptimal") things exactly 
because it does incremental changes that DO NOT BREAK at any point.

The examples are legion. The mammalian eye has the retina "backwards", 
with the blind spot appearing because the fundmanetal infrastructure (the 
optical nerves) actually being in *front* of the light sensor and needing 
a hole in the retina to get the information (and blood flow) to go to the 
brain!

In other words, exactly *because* evolution requires "bisectability" (any 
non-viable point in between is a dead end by definition) and does things 
incrementally, it doesn't do big flips. It fixes the problems on an 
incremental scale both when it comes to the details and when it comes to 
both "details" (actual protein-coding genes that code directly for some 
expression) and "infrastructure" (homeobox and non-coding genes).

So quite frankly, you're the "intelligent designer" here. You're the one 
who seems to claim that we need those leaps of faith and wild jumps.

> Oh, it's been painful at times, but they are, overall, very rare.

No, overall, they have *not* been rare lately. We've had them all over. 
And not just the one introduced by you.

> If you look at the rate of change we are currently running at, it's
> amazing that we do not get _more_ of these kinds of problems.

I don't think that's a valid argument.

Sure, we have lots of changes, but 99.9% of them have no cross-subsystem 
effect what-so-ever.

> > And simply avoiding cross-subsystem API changes unless there is a major 
> > *MAJOR* reason for them is the obvious thing to do. Simply face the fact 
> > that even in open source there are major reasons to stay with an old 
> > interface even if it's not optimal.
> 
> I strongly disagree here.  We lived with that kset/ktype crap for years,
> and I finally broke down and cleaned it up, simplifying things, removing
> code, making the kernel smaller, leaner, and easier for others to change
> and use in the future.  With your statement, such a change should have
> never taken place as it what we had at the time was "not optimal", but
> good enough to live with.

You didn't listen at all.

I said that the threshold should be high, not that it should be 
impossible. I also said that we should strive for making it unnecessary to 
have the painful total synchronization points.

The fact is, we *have* been able to do things like this gradually and 
well, without introducing breakage. Take the VM changes, for example: 
those were pretty damn fundamental, where we've changed the calling 
convention totally for fault handling.

But that thing was done without at any point really seriously breaking 
code. It involved adding the new interface, and letting the old one live 
in parallel. 

The last remnant of the old "nopage()" interface still exists, but I think 
right now it's only used by DRM. 

Did it require the drivers to be updated? Yes. But it did NOT require the 
total synchronization, because it still worked with the old interface.

> But they do happen about once or twice a kernel release, just by virtue
> of the way things need to happen.

And I violently disagree.

It should not be "once of twice a kernel release".

It should be "once or twice a year" that you hit a flag-day issue. The 
rest of the time you should be able to do it without breakage. It's 
doable. You just HAVEN'T EVEN TRIED, and seem to be actively against even 
doing so.

		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/