Ian Romanick wrote:
Michel Dänzer wrote:

On Wed, 2003-10-22 at 20:38, Ian Romanick wrote:

Eric Anholt wrote:

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.


Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes.


That won't be necessary in any case; once there is a chip (which we
support...) with a 64 bit address space, just add a parameter to set the
high 32 bits. :) I don't mind either way, but I don't feel like figuring
out which type to use for a 64 bit value and dealing with the build
problems it might cause right now.


I added Keith's proposed struct with int64_t as the value, and I added '#include <inttypes.h>' to xf86drmCompat.c. Everything compiled fine.

As a side note, at what time will we be able to deprecate xf86drmCompat? Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway.

We can definitely remove the xf86drmCompat layer for XFree86 5.0. I believe it's well understood that major version changes will break existing binary interfaces.


--
                               /\
         Jens Owen            /  \/\ _
  [EMAIL PROTECTED]  /    \ \ \   Steamboat Springs, Colorado



-------------------------------------------------------
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

Reply via email to