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] [day] [month] [year] [list]

Message-ID: <4B22862E.5050407@garzik.org>
Date:	Fri, 11 Dec 2009 12:49:34 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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 12/11/2009 10:28 AM, Linus Torvalds wrote:
>
>
> 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).

At the outset, I was hoping for an even more straightforward solution: 
"if nouveau kernel mod not present, fall back to nv"  That would work 
without any kernel modifications at all.

But the answer came back as "if you run Fedora, run a Fedora kernel, 
otherwise don't expect anything to work"  My experience directly 
contradicts claims of "upstream first" policy, both in code and attitude.

I am looking into doing the git tree merge you suggest right now....  I 
didn't know that was an option, given ongoing API changes.  That would 
make my life quite a bit easier.  As you note, anything graphics is 
_glacially_ slow due to vesa fallback, when using a 100% upstream kernel.

	Jeff


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