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]

Message-ID: <20100304150519.7d7345b0@jbarnes-piketon>
Date:	Thu, 4 Mar 2010 15:05:19 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Stephane Marchesin <stephane.marchesin@...il.com>,
	Dave Airlie <airlied@...ux.ie>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

On Thu, 4 Mar 2010 14:54:03 -0800 (PST)
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 
> 
> On Thu, 4 Mar 2010, Stephane Marchesin wrote:
> > 
> > In short, the "don't break user space interfaces" principle is making
> > user space code quality worse for everyone. And it makes our lives as
> > graphics developers pretty miserable actually
> 
> And _my_ point is that if you did a half-way decent job on versioning, you 
> wouldn't be in the crappy situation you are now.
> 
> For chissake, the DRM versioning model is a total disaster. The reason you 
> can never ever break user space interfaces is exactly because when you 
> break them, X stops working.
> 
> What I suggested is to _keep_ a working model across different versions, 
> so that you can get out of the rat-hole you are in now (and the rat-hole 
> you put your users into, and the distributions).
> 
> It's simply _not_ acceptable to tie the X server and the kernel version so 
> tightly together as the crazy DRM model does right now. It's not all that 
> different from us requiring people to install a new glibc every once in a 
> while, just because we added a new filesystem. Everybody understands that 
> that would be totally insane.
> 
> Why does the X community not understand simple library versioning?

We use versioning on the Intel side, but in the form of feature flags
as new things are added (we've had a handful since GEM was added in
2.6.28).  It's a pain to handle the various code paths, but no more so
than having lots of separate library versions to support.  That would
be nice from one perspective, but it would only save work if we
abandoned the old versions quickly and kept a big shared component
between library versions.

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