On Tue, 2003-10-21 at 11:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam {
> > int param;
> > int value;
> > } drm_radeon_setparam_t;
>
> If this is done, I would *strongly* suggest that the type of value by
> int64_t or something similar. We have enough places where mixed 32/64
> systems will break, we don't need to add more. On PPC64 where mixed
> mode is supported, sizeof(int) != sizeof(void*). I assume the same is
> true on IA-64, x86-64, and SPARC64.
>
> Other than that, I am in favor of adding this as a more generic interface.
Would we ever be setting pointers through a setparam interface? I think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_t for the drm (and dri
screen private?) sruct definitions everywhere to make things clear.
Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and
64-bit longs and pointers.
Hmm, just noticed that the SiS dri/ddx/drm interactions are rather
64-bit unclean. I thought I had fixed that.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
