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
