> > > > 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?
Okay incompatible interfaces are not acceptable unless they are major version number changes. Minor or patch version changes should not break the kernel interface in any way unless its a major security hole being solved, and even then a major version bump is probably preferred. Userspace should always be able to work with the major number it expects, it can also place a lower bound on minor numbers if it wants, but it should not require an equality of minor or path. If we have shipped a minor version bump in the upstream kernel that breaks userspace point it out and I'll revert it. Now if a certain vendor ships kernel patches without testing or posting them upstream first, then there isn't much we can do except bitch at the clueless maintainers of that kernel. > 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. The thing is the major number is all you should need to carry really, the userspace API isn't just defined by this header file, other thing internal to the module can affect the API like the command stream verifier. So the kernel could require a drm minor bump for some new verifier restriction, and this header file wouldn't change at all, or would just have a pointless version number bump. So the kernel version should not be tied directly to this file version either. > > 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? It doesn't allow for major version number changes gracefully at all, nothing does, if the kernel suddenly only produces a version 3.0 via drm API it will break all current VIA userspace drivers, this would never be acceptable *ever*. For KMS we have made an exception as its a requirement that people update userspace to enable KMS, but we've also made sure we enver enable these by deafult upstream, only at a distro level where hopefully they realise they need a compat userspace before turning stuff on. > 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? > A clean updated patch to the kernel, but really nothing you've said convinces me in any way this isn't just an attempt to workaround a crap developemnt process where nobody is maintaining API compatability. > > 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.) Okay so if that is these patches, then that is an issue, Novell screwed up by not upstreaming this first, but thats not uncommon. > > 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. You can't gracefuly handle major bumps, unless you count disabling DRI on someones working system acceptable which we don't anymore. The only way I can think to do a major number rest is with a Kconfig option that distros can enable for that driver, sort of like what we did for KMS. I can't see why adding a while new set of icotls at the current API level, won't work, userspace that wants the bug fixed can just use the new APIs, older userspace users the old ones. 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
