On Fri, Sep 11, 2009 at 05:02:47AM +0100, Dave Airlie wrote: > > They shouldn't have to. At build time they just require a certain version, > you shouldn't be building half the features into the driver because it > has an old _drm.h file. In an ideal world we would have all this stuff > hidden at the libdrm level but that never happened. So generally drivers > now do one of two things. > > a) get a copy from kernel/libdrm, if its not new enough get a newer one > installed, i.e. normal dependencies. > b) ship a copy of the header file with the driver to build against it. > > The kernel API is runtime compatible it shouldn't have incompatible > changes, so at driver startup it asks the kernel the version and does > the right thing for that version, again this versioning has no use. > > So if VIA drivers were developed in a reasonable fashion none of this > would be necessary really, its seems like a technical workaround to a > social issue, since no other DRI driver has required it.
What should the canonical source of such versioning information be? * This header file defines the interface, and this versioning included in the same headerfile should then niquely identify this interface. * driver builds against this header and should then require this version of the interface from the drm as well. It might choose to have some build time or run time workarounds if the developer decides to spend time on this, but it doesn't need to. * drm gets built with this header and uses this versioning information to tell the driver what interface it is running against. I really do not see what is wrong with providing interface versioning for a drm driver, and why this interface versioning information should not be coming with the interface definition. I see a very logical and direct connection between the two. > When someones sends patches to this list, I generally try to review them > as I'm the kernel maintainer. Since VIA patches have been known to either > a) languish b) be ignored c) spat on d) end up being political, I'd like > to try and have some sort of actual technical input rather than, my 15th > branch, once removed VIA driver will break if you do this. > > And VIA have requested I look at patches to help them figure out the > process, you know actually be useful instead of bitch about the way > things were 4 years ago every time anyone tries to move forward. Now this patch, it is something that fixes up the issue with their own via driver. There was no attempt made to communicate with either real open source project to get this interface change accepted there too. So it fixes an issue that possibly might have been seen with VIAs own driver, which not that many people are shipping today still, but in return is breaking those driver(s) that people are shipping today. Now the fact that there are three driver versions, each of which is hairy and defunct in its own particular way for its own particular reasons, is what is important here, not why this got to be such. What is important is how this situation is dealt with with respect to other parts of the graphics driver stack. And this "how" translates to "not at all". This does not seem like "trying to move forward" to me. Luc Verhaegen. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
