On Fri, Mar 5, 2010 at 6:19 PM, Linus Torvalds <torva...@linux-foundation.org> 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 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel