Ian Romanick wrote:

So, for whatever reason, size_t is used in drm.h in several structures that are shared between user and kernel. HOWEVER, xf86drm.h uses int in those places. Is it safe to assume sizeof(int) == sizeof(size_t)? If it is, then I'm going to change drm.h to use int for now. We *really* need a flag day to just fix all this stuff...

After talking to some folks on #dri-devel, I learned that, even though there is this mismatch, DRI does work on LP64 platforms. I went searching to find out how it could possibly work, and I found the function drmCopyVersion. I then became sick to my stomach.


Part of the problem is that I want to use drm.h in the X-server, and we can't use size_t there. I *think* we can work around this by creating a new temporary type called DRM_SIZE_T that we define as:

#if sizeof(sizeof(char)) == sizeof(unsigned int)
# define DRM_SIZE_T unsigned int
#elif sizeof(sizeof(char)) == sizeof(unsigned long)
# define DRM_SIZE_T unsigned long
#else
# error EVIL!!!!
#endif

It's a horribly hack, but we could get rid of drmCopyVersion (and related functions) AND use drm.h in the X-server AND keep binary compatiblity. The only thing that changes is the interface to libdrm.a, but that doesn't matter because it's statically linked.

That said, we need to make a concrete plan to resolve this 32/64 crap ASAP. This is just *horrible*. Here is my suggestion:

1. We declare that from 1-June-2004 until 1-July-2004 DRM version and user-mode DRI version must be kept in lock-step on LP64 platforms. Plan on day-to-day breakages. This is the period during which everything will be "fixed."

2. Starting 1-June-2004, all "old" DRM versions and user-mode DRI versions will be declared "dead" on LP64. If you're not a developer, keep what you have until 1-July-2004 or see #1, above.

3. Starting 1-July-2004 there will be no further (intentional) user / kernel binary compatibility breakages. From that point on, all user / kernel interfaces must use explicitly sized types (i.e., int32_t, uint64_t, etc.) instead of built-in C types (i.e., int, long, void *, etc.).

We should discuss this in Monday's #dri-devel meeting. I expect to be around. Monday is a holiday in the US, so I'm not sure how many other people in the US will be around.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to