Luc Verhaegen wrote: > On Fri, Sep 11, 2009 at 05:54:34AM +0100, Dave Airlie wrote: > >>> 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. >>> >> No thats where you got it wrong, a driver should never *require* version >> of interface at runtime == version of interface at build time. We >> rarely make incompatible major number changes in the kernel drivers, >> (radeon kms being the first in my memory). DRM drivers ship in the >> kernel, not separately so dealing with inequality of version isn't >> optional. >> > > It is exactly such a major change that made this version numbering > necessary in the header file. > > >> So from what I can see this solves a compile time problem, not a run time. >> Generally this has been solved in other ways, either requiring when >> the driver needs a newer version of the header it requires a new libdrm >> or when the driver needs a newer version of the header it ships it within >> itself. >> > > No it is not, the interfaces are not compatible. This patch will not > be put in everywhere immediately. How does a graphics driver give the > user a reason for why the whole thing came crashing down, while things > worked just fine before the kernel update that joe user most likely > will not immediately see as the reason for this breakage? > > I really do not see what the problem is with having the driver version > carried around in the interface headerfile. X driver, mesa and drm > driver build with that. drm claims this version. If this version is not > compatible, both X driver and mesa can then try to handle this > gracefully. If you choose to have the driver fail hard with an error > message, then fine, it at least is better than having half the userbase > complain that their drm wasn't initialised fully, for no visible > reason. > > >> Its just not been required before and I'd like to understand why no-one >> else has had the requirement over the other 8 or so drm/dri drivers >> produced. Generally I think we avoid it because it links the build and >> runtime versioning, which isn't something that a driver should ever do. >> > > Isn't versioning a common scheme to be able to handle both run and > build time compatibility in a halfdecent manner? What use is > runtime-only or buildtime-only versioning? > > Are you against this because carrying a versioning information makes it > possible to do major changes gracefully and therefor encourages major > changes and therefor is totally unacceptable? > > That almost sounds like saying that people shouldn't use electricity at > all because it could mean that a whole team of people in a nuclear > power plant will end up doing the wrong thing, every few weeks. > > >> But if *chrome all agrees its a good plan, then I'll take a patch, >> it would be nice if TH signs off on it. >> > > We discussed it out fully 3.5 years ago, and TH committed it 3.5ys > ago, and he has nicely kept up the version bumping since from his side. > > What is it that you still require here? > Yes, IIRC we moved that over to via_drm.h because Luc wanted a full check at compile time for the unichrome driver, whereas openchrome knows what DRM versions it works with and judges the compile-time compatibility from other defines.
While I don't think it's necessary, I have nothing against having versioning in via_drm.h. /Thomas ------------------------------------------------------------------------------ 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
