On Fri, Sep 11, 2009 at 11:00:27PM +0100, Dave Airlie wrote: > > 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.
Are you saying "Yes, it is right to carry version information in the drm.h file"? And yes, the usage of major, minor and patchlevel is clear, and didn't really need repeating. > If we have shipped a minor version bump in the upstream kernel that > breaks userspace point it out and I'll revert it. No, you didn't ship it, yet, and exactly to stop this from shipping the major issues i have with these patches were pointed out. > 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. That part was being taken care of, and by pointing out the problem, i hoped that it would first finally really get reverted, and secondly not happen again for the same set of patches. > 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. But why not have all three numbers _in_ _the_ _same_ _place_. Disperse them, and sooner or later someone tries to be smart and then breaks the versioning scheme. Userspace is free to try to be compatible as much as it wants then, or ignore as much as it can, or it can just stupidly break down and cry loudly when just the patchlevel gets bumped. At least you get good feedback. > It doesn't allow for major version number changes gracefully at all, > nothing does, Depends on the definition of gracefully. I fully agree that major bumps should be avoided at all cost, but they are sometimes impossible to avoid. And then we can try to deal with it as gracefully as possible. > 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*. Hence my statements in the original mail. > 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. For unichrome, the dma stuff suddenly lost bouncebuffer (iirc this was once used for pitch conversion) support and the respective structure members. Now in autotool-world, you can check headers for that easily, in Imake world, things were not that easy. One can easily make things buildtime compatible, by providing version numbers in the header file, and by bumping the major number. Runtime compatibility can then be checked easily by using the major define directly. I still do not see why you are against this. It is not exactly rocketscience, it solves some of the problems we were facing, and it works. > 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. To be able to deal with things, the version numbering was introduced. API compatibility would have had a better chance of surviving if the versioning was also put in the kernel tree. This whole situation clearly reeks of a broken process. Have you recently diffed the mesa/drm and the kernel/drm and seen what the differences are, or are you just grabbing patches from one and putting them in the other, letting both trees grow apart over time? > Okay so if that is these patches, then that is an issue, Novell screwed up > by not upstreaming this first, but thats not uncommon. This were VIA patches sent to the dri-devel ml which got ignored completely. Gregkh used these patches that never really became upstreamed, and then failed to even warn the SUSE X developers about it (at least, i missed it at the time it was included, and i was still there, not 100% sure about the others, even though i am sure that i would've been told this immediately). Novell did not have to upstream itself, so please stop suggesting that this was Novell doing stuff behind closed doors. Surely redhat never used/shipped code that wasn't fully upstream yet. And no, i am not trying to talk good what gregkh did (and here it is just that, gregkh did something wrong), but i also cannot stand the constant overtwisting of "what novell did". Novell can be bashed comprehensively enough without having to twist the truth. Novell doesn't need the constant redhat FUD, it is perfectly able to shoot itself in the foot. And please do not try to use the above statements out of context either. > 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. It is better for a driver to throw up its hands and state clearly what is going on than to break without a clear reason. Carrying versioning information around allows userspace to immediately tell what happened and gives joe user a better hint at what he can do to get it fixed. > 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. In this case, it is clear that one of the new ioctls should be used before the old ones are useful. In fact, dri initialisation fails completely without this. Hence my original mail. With this whole thread i get the standard feeling i have when i put some effort into communicating with you and some others. I state what i see as pretty obvious, and it gets trashed with little to nothing backing the thrashing, then i have to spend ages patiently trying to explain what i see as pretty obvious, in a way that it cannot be baselessly thrashed anymore, which often means repeating things a lot (and yes, i do not have the patience for that). Now what i am wondering is, are these things really not obvious, or are you just naysaying things for other reasons? Luc Verhaegen. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
