On Mon, 15 Oct 2001 11:36, Daryll Strauss wrote: > On Mon, Oct 15, 2001 at 10:14:33AM -0600, jhartmann wrote: > > If you have demenstrated that this is the case then we should remove the > > version system then I guess. I do want to voice my concerns though by > > writing out my argument fully though. > > Having a version system is safer. If something does require an > incompatible change, like the security fix in the Radeon, then you have > some way of invalidating earlier versions. If it turns out that we can > keep all the versions compatible that's even better and you just don't > indicate that the version change was an incompatible one.
The radeon fix could be acheived in a backwards compatible way by doing a copy in the kernel. Acually you would have to do this even with a version-setting-ioctl: if the old version is set, you still have to implement the functionality in a secure way. If a new techinque is needed for a fast *and* secure texture upload, then you have to add it in a new ioctl. But there's nothing gained by having an ioctl to tell the kernel which one you are going to use - the kernel needs to implement both versions and it doesn't really care which one you use. > Therefore the version system just becomes a safety net and costs us > nothing in runtime overhead. In practice, we want to strongly discourage > incompatible changes, so it acts like Keith is recommending. Actually it doesn't acheive anything. There's no pretending that you don't have ioctls that you really do - that's all a versioning scheme can acheieve (ignoring the sarea snafu, of course). We don't want to discourage backwards-incompatible changes, we want to outlaw them. 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
