linux-kernel - Re: [git pull] drm fixes

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: <20110325104609.2380f08e@jbarnes-desktop>
Date:	Fri, 25 Mar 2011 10:46:09 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Jerome Glisse <j.glisse@...il.com>
Cc:	Dave Airlie <airlied@...il.com>,
	Michel Dänzer <michel@...nzer.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes

On Fri, 25 Mar 2011 10:04:10 -0400
Jerome Glisse <j.glisse@...il.com> wrote:

> My feeling on that is that maybe too much code sharing accross gpu of
> different generation hurt more than it helps. I have got the feeling
> that some of the newer Intel asic share some of the bit of older one
> and that intel is focusing there attention on newer one and obviously
> doesn't have time or resource to check that change they do don't
> impact older hw (i don't think such testing is doable without massive
> investment which is very very unlikely to happen given size of linux
> market).

God yes.  The mantra of "code sharing is always good" sounds nice, but
in my experience it's very often not true, especially when you're still
trying to get things to work.

We've been slowly splitting code out to make it more robust against
changes to different generations, but we still have a little ways to
go.  And of course, such splitting introduces problems in itself.

But as a policy going forward, I'll advocate splitting code whenever a
new generation requires something slightly different than an old one.
As an example, rather than adding a few conditionals to our FDI
training code to support newer chips, I've split it into separate
functions entirely, leaving the old one alone.  If, after awhile we've
decided that they really are mostly the same and we have things working
well, we can consider merging them again, but only after extensive
testing across generations.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/