Thomas Hellström wrote: > >> >>> Is this meant to be backwards compatible with an older kernel? In >>> that case >>> we should bump DRM_BO_INIT_MINOR. If not, we should put the new >>> member with the other 64-bit members at the top of the struct and >>> bump DRM_BO_INIT_MAJOR. >>> >> >> Yes, it should be backward compatible. The req is smaller than the rep, >> so adding new members won't change the alignment. Also, as the flag >> indicates whether the additional data is present, older clients won't >> accidentally trigger the optimization. Furthermore, as this is purely an >> optimization, newer clients needn't even bother to check for the kernel >> version. We can bump the minor version, but I'm not going to add checks >> for it. >> >> >> > OK. No bother bumping then. > > /Thomas > Ugh, Actually I do think we need to bump major. Consider the case with an old client and a new kernel; the new kernel will copy the new size whereas the old client provides only the old size, which may lead to copy_from_user() failing.
So if we bump major we might as well group the new member with the other 64-bit members. /Thomas /Thomas ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
