Jeff, Others, I've been reviewing the work in the 3.5 branch for backwards compatibility and to me it looks like we can do it with a lot less effort. Here's what I'm proposing, in one simple sentence:
Instigate a rule where any released ioctl will always be supported, with the same semantics and interface. This sounds simple and has a few consequences. First and foremost is that the use of the sarea for passing parameters is deprecated. Any new ioctl will take all its parameters through the ioctl struct, even if that means some performance issues. I don't think it will however. Secondly, it means no ioctls are ever removed or renamed. This was Linus' big concern and he was right. If new functionality or a varient is required, it will always be a new ioctl. There's no need for a versioning ioctl under this scheme, because all it could do is turn off some ioctls that are never going to be used anyway, so what's the point. Under this scheme all 'versions' are just subsets of the full functionality, setting a version doesn't alter the behaviour of any ioctl, so there's no point in setting a version. So, the 3.5 branch kernel component now looks identical to the trunk with a small number of new ioctls. I think this is closest to how the kernel people expect interfaces to be treated, and after coding it up it really makes a lot of sense. Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel