Message-ID: <alpine.LFD.2.00.1003041142250.3751@localhost.localdomain>
Date:	Thu, 4 Mar 2010 12:01:28 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...il.com>
cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3



On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> At the moment in Fedora we deal with this for our users, we have 
> dependencies between userspace and kernel space and we upgrade the bits 
> when they upgrade the kernels, its a pain in the ass, but its what we 
> accepted we needed to do to get nouveau in front of people. We are 
> currently maintain 3 nouveau APIs across F11, F12 and F13.

Can we try to make it less of a pain in the ass at some other level?

For example, I realize that it's a real pain - both for the kernel _and_ 
for the user space library - to dynamically have to support multiple 
versions of some interface. 

And doing it _statically_ (with a compile option) isn't much better, 
because you end up not only with source code from hell, you still end up 
with the problem of having to compile the libraries and the kernel for the 
same interface, and not being able to mix.

So let's say that we live with an API that changes, where none of the 
binaries (and no single version of the source code either) really support 
anything but _their_ version of the interface.

Why does it then have to be such an effing pain for the _user_?

(And by being such an effing pain for the user, it also becomes indirectly 
a pain for the distribution too - now you have all those nasty 
dependencies where you really cannot mix things up at all, and you can't 
upgrade one piece without upgrading the other).

> Now I can ask Ben if he'd like to try and supply a libdrm that could in 
> theory deal with both as a favour, but I'm not expecting the nouveau 
> project guys to care, we pretty much got ourselves into this corner, and 
> we'll pretty much have to get ourselves out.

Quite frankly, I really don't think that's a wonderful option either. 
Havign dynamic conditionals in code not only makes things worse to 
maintain, they slow things down too, and make code bigger.

So what I'd look for is a sane technical solution to the technical problem 
of "that ABI screwed up". 

And it's not like this is a new issue. We've had this several times 
before. It's called versioning, and the solution tends to pretty much 
_always_ boil down to two cases:

 - don't _ever_ change the ABI in backwards-incompatible ways, and have 
   "feature flags" to say what level of support ther is.

   This is quite common, but it really does require that backwards 
   compatibility. You can add features, but every time you add a feature, 
   you still maintain the old ones _and_ new users need to check the 
   feature flag first (and fall back on the old way of doing things if the 
   new feature isn't there)

   Clearly this one doesn't seem to work for DRM. And quite frankly, I 
   suspect it's at least partly because some DRM people aren't even
   _trying_ - possibly because they aren't even thinking about these kinds 
   of issues.

 - Install multiple versions concurrently, and know they are incompatible, 
   but pick the right one automatically.

   I really don't understand why this wouldn't solve all your distro 
   problems, _and_ solve my kind of user problems too. It's simply not 
   acceptable to just say "ok, X doesn't work". Why aren't the libdrm 
   libraries simply _versioned_?

   IOW, why can't we just have 

	/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.15.so
	/usr/lib64/xorg/modules/drivers/nouveau_drv-0.0.16.so

   living happily side-by-side? Why can't we just switch between Fedora 
   11, 12 and 13 kernels, and automatically get the right library? The 
   glibc people do it based on hardware features. It's just a "dlopen()" 
   away.

This isn't rocket science. I shouldn't need to complain. I think it would 
make the life of even the _developers_ much easier.

Who was the less-than-rocket-scientist that decided that the right thing 
to do was to "check the kernel DRM version support, and exit with an error 
if it doesn't match"?

See what I'm saying? What I care about is that right now, it's impossible 
to switch kernels on a particular setup. That makes it effectively 
impossible to test new kernels sanely. And that really is a _technical_ 
problem.

Btw, I'm sure there are other approaches too. But I really suspect that it 
should be pretty trivial to change nouveau (and I suspect this has nothing 
nouveau-specific in it - it migth even be the X server itself that does 
the DRM version test) to instead of dying, just doing a dlopen() of the 
right version.

Wouldn't the radeon and intel driver people love to be able to do 
something like that -too-?

Seriously. The current situation is not just crap, it's _stupid_ crap.

		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/

Powered by blists - more mailing lists