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:	Thu, 4 Mar 2010 19:24:15 -0500
From:	Kyle McMartin <kyle@...artin.ca>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...il.com>,
	Stephane Marchesin <stephane.marchesin@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

On Thu, Mar 04, 2010 at 03:53:32PM -0800, Linus Torvalds wrote:
> Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
> you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
> it to be a _major_ pain to have that whole hardcoded "X and kernel must 
> always change in lockstep".
> 

Frankly, I completely agree with you. This kind of shit makes it
extremely difficult for users to run, say, 2.6.33 on F-12 without us
doing a backport. Thankfully Ben takes care of that for me, usually,
by keeping nouveau up to date with upstream in the various Fedora's, but
it's still a set of shackles that I'm pretty sure none of us want. (Not
only that, but it means if you update, you may need to do a full reboot
before you can start X again, which is pretty disappointing.)

For example, right now, Fedora 11's 2.6.30 kernel has nouveau 12, with
nouveau 12 userspace. For Fedora 11's 2.6.32 kernel, instead of updating
the userspace stuff, I forward ported the old DRM entirely, bringing
with it whatever bugs it had, simply because DRM is such a nightmare.

It's already impossible to run Fedora 13's 2.6.33 kernel on 12 since Ben
put the nouveau git changes for the new ABI in there already. So we'll
have to drop those from the F-13 2.6.33 for the F-12 2.6.33...

This situation /sucks/ for users. Personally, I think we committed to a
stable update ABI when nouveau got a MODULE_DEVICE_TABLE and started
binding by default. But hey, I'm just the kernel maintainer, and I
didn't pipe up then, which was my mistake. If we're going to ram
something at users by default, we should at least try to guarantee that
they'll be able to restart X and have things continue to work.

That said, whether you think it's a lame excuse or not, staging was
clearly labelled as buyer beware.

I'm personally sorry that you got burned by nouveau on Fedora both these
times, but we're really just trying to help, and not hinder things.
(Maybe I should commit a patch to rip out the module aliases for
nouveau, but I suspect I'd have more people screaming for blood that
way. Sigh.)

regards, Kyle
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ