On Wed, 12 May 2004, Dave Airlie wrote:
I just looked at drm.h and nearly all the ioctls use int, this file is included in user-space applications also at the moment, I'm worried changing all ints to __u32 will break some of these, anyone on DRI list care to comment?
Right now, all architectures have "int" being 32-bit, so nothing should break. Apart from sign issues, of course.
If there are pointers and "long", then those should just not exist. Never
expose kernel pointers to user mode (and you really never should pass user
pointers back), and "long" should really just be "__u32" instead (since that is what it is on a 32-bit platform - and if it works there, then it should work on a 64-bit platform too).
Right. We came to that same conclusion when this issue came up a year ago. The problem, and I suspect the reason nothing happened, is that we have a potential binary compatibility problem. As a concrete example, if we change all instances of "unsigned long" to __u32, user-mode drivers built to that interface will break with currently installed DRM drivers on all 64-bit platforms. At the same time, on "pure" 64-bit platforms (like Alpha), changing (only) the kernel will also break things. That makes this a case where bumping the DRM interface version number won't even help. :(
Clearly leaving things as they are is not viable. Going through and doing s/unsigned long/__u32/g isn't much better. Anyone have a 3rd option? :( Or is the installed 64-bit user base small enough that we can make them take one for the team, so to speak?
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
