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? > Is this not an attempt? generally all patches to the drm go to this list > first, yes maybe they should also go to *chrome lists, but maybe > developers who care should be more involved with the dri process instead > of having their own one on a list that is somewhere else. > > The questions we ask here are generally: > a) does this break runtime ABI in a backwards incompatible manner? > b) does this patch have major style problems. > > So far (b) is true, and you've stated (a) is true but I haven't seen > the lines in via_drm.h where this is pointed out. a) https://bugzilla.novell.com/show_bug.cgi?id=521382#c0 where Reinhard Nissl clearly describes the lowlevel part of the problem (and where i, without a log, completely missed the far-reaching consequences of this; ie, no working drm at all.) > The other question is whether the new API makes any sense, and I can't > answer that, which is probably where we need you or Thomas to chime in > and tell us why its technically incorrect. > > Dave. I cannot immediately answer this API thing either. I saw this bug report pointed at me, and only a bit later realised what really was going on. This patch was included very late, and we were never given a heads up on this, let alone told exactly what it fixes or how this can be reproduced. It just blatantly broke things, and then the only quick answer is: revert. Chances are that if this is looked at differently, everyone can become happy without a major version bump. If not, there should be a major version bump and all players should gracefully handle this. 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
