Re: [git pull] drm request 3

From: Felipe Contreras
Date: Fri Mar 05 2010 - 15:59:30 EST


On Fri, Mar 5, 2010 at 6:19 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> The thing I objected to, in the VERY BEGINNING in this thread, i the fact
> that the thing was done in such a way that it's basically impossible to
> support the old/new ABI at all!

[...]

> The way this was done, it's apparently basically impossible for the Fedora
> people to push out packaged that support both the old and the new kernel.

The reason why the nouveau people wanted to leave the driver in
staging is because they wanted to leave open the option of reshuffling
the API. The Fedora guys integrated this stuff on their own risk, and
linux (because of your pressure), also did. At no point in time
nouveau guys agreed to freeze the API.

Now they have done precisely what was expected; there's no surprise there.

The surprise seems to be that you thought (for some reason), that
reshuffling the API wouldn't break the old (or current in F12)
user-space code. Now, how exactly do you think that could have been
achieved? Even if you have both nouveau_drv-0.0.15.so, and
nouveau_drv-0.0.16.so... What piece of could would choose one rather
than the other? There has never been such a piece of code.

If there was no compatibility code for API re-shuffling, and API
re-shuffling was expected, the resulting breakage was doomed to
happen.

Finally, at least it's possible to compile the radeon driver without
support for DRM, so perhaps nouveau (and other drivers), should check
the kernel drm version at run-time instead, and fall-back to non-drm
mode when the version is not compatible. I think that's a sensible
approach, although that might require a considerable amount of code.
However, that's something to consider for the future, as your current
libdrm/nouveau is not prepared to handle the DRM API re-shuffle that
_must_ happen.

Cheers.

--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/