linux-kernel - Re: [git pull] drm

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.2.00.0912110710510.3560@localhost.localdomain>
Date:	Fri, 11 Dec 2009 07:28:42 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Stephane Marchesin <stephane.marchesin@...il.com>,
	Maarten Maathuis <madman2003@...il.com>,
	Xavier Bestel <xavier.bestel@...e.fr>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm

On Fri, 11 Dec 2009, Jeff Garzik wrote:
> 
> F11 uses nouveau here.  It is actually a pain to get 'nv' going as an
> alternate -- bugs have been filed.  Makes kernel dev more difficult for me.  I
> was actually told, by Fedora people, that I should be hacking on the Fedora
> (rpm-based) kernel, rather than a 100% upstream kernel like I have been
> hacking/booting for the past decade, as a result of this setup (needing
> nouveau kernel support, thus needing Fedora rather than upstream kernel).

Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the 
wrong people - it's just that the actual driver authors aren't the ones 
that violated any rules), I do have to give kudos for the fact that the 
F12 situation seems to be much better.

These days, what you can do is basically do all development (assuming it's 
not nouveau development) in the upstream kernel, and then you just have a 
separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff 
into.

That tree/branch will be a mess of random merges-of-the-day, but you'll 
never push it out to anybody anyway, so nobody cares. And building that 
messy merge tree will get you a working setup without any extra steps - a 
simple "make modules_install ; make install" will JustWork(tm).

So it's much more straightforward than it used to be (you had that 
separate tree that you could build modules in), you can basically build 
things exactly the same way you are supposed to do things _anyway_ if you 
have experimental branches etc and want to build in a temporary merged 
tree (even if you're not actually ready to merge it all and still want to 
keep the branches separate).

Of course, it's a good thing that it's easier in F12, because in F11 if 
you forgot to build the nouveau stuff, it would just fall back on the VESA 
FB setup - you had a working system, it was just very slow X. You could 
then build the nouveau modules you forgot about, and re-start X.

That "oops, I forgot" case seems to no longer work at all in F12 - if I 
build without Nouveau on my nvidia machine, the kernel will boot, but I 
will have neither working X _nor_ a working text login. So there's no way 
to even build the modules and fix it up - you have just to re-boot back 
into an old kernel. Very annoying for bisection.

			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/