linux-kernel - Re: [git pull] drm request 3

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:	Fri, 5 Mar 2010 08:07:23 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
cc:	daniel@...ishbar.org, alan@...rguk.ukuu.org.uk, skeggsb@...il.com,
	airlied@...ux.ie, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, dri-devel@...ts.sf.net, mingo@...e.hu
Subject: Re: [git pull] drm request 3

On Fri, 5 Mar 2010, David Miller wrote:
> 
> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.

Now, I agree that that would have been the optimal setup from a testing an 
user standpoint, but I think it's a bit too strong.

Things don't need to be "frozen", but flag-days need to be avoided. The 
problem with flag-days is not so much that they need new support code: 
downloading a new version of something like X is not a huge issue. But 
flag-days work both ways: it's not just that you have to download a new 
version, it's that you can't go _back_ either - not even a little bit.

For example, I can now test my new kernel, but if it turns out that there 
are problems with it, I'm now officially screwed. I can't go back and rely 
on even the stable distro kernel, like I'm used to ("ok, that _really_ 
didn't work, but happily I didn't remove the distro kernel, so I'll just 
reboot with that"). And I certainly can't bisect without major problems.

And Fedora can't install the new libraries, because they won't work with 
their own old kernels either. So it effectively causes a version freeze: 
it looks like F12 will simply _never_ be able to support a 2.6.34 kernel, 
because if they do that, then everybody who gets the new packages (and has 
a nvidia graphics card) will now be stuck.

So flag-days really are bad. They're bad for users, they're bad for 
distributions, and they're eventually bad for developers too because now 
they lose a lot of every-day testing. Some day, F13 will come out, and the 
_only_ testing all the new code ever got was the (relatively small) 
rawhide community, and the kernel crazies who did things manually.

But even if you can't guarantee backwards compatibility, if you avoid the 
flag-day, and can have a new version of the environment that can handle 
both the old and the new model, you _could_ install that on F12 (before 
switching kernels), and not be in that effective version-freeze.

Yeah, you'll still have a dependency chain, but it will be a one-way one, 
so you're not stuck. As long as you have the newest vesion of whatever 
libraries or support, you can go back-and-forth and test development 
systems.

And we do that for the kernel in many other respects. We require that you 
have a "recent enough" compiler, for example. So there are already lots of 
those one-way dependencies where we're not infinitely backwards compatible 
with user space, but we've been pretty good at not having flag-days.

				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/