> > 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. 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. > 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. 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. 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. > > > 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. 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. 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. ------------------------------------------------------------------------------ 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
