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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ