Paul Mackerras writes:
> Egbert Eich writes:
>
> > Exactly. If we want 32 and 64-bit pices to work together we need 32bit
> > handles. If you pass a 64bit handle to a 32-bit client it's useless
> > as mmap() cannot deal with a value in offset that doesn't fit into
> > 32 bit. - at least unless we set -D_FILE_OFFSET_BITS=64. However this
> > may have other undesireable side effects.
> > If we abandon the idea that handles might be real physical addresses
> > then we can use handles that fit into 32 bit
>
> My point is that if we are going to use 32-bit handles, we have to
> convert handles to 32 bits for 64-bit processes as well as 32-bit
> processes. I don't see your patch doing that.
>
>From
https://bugs.freedesktop.org/attachment.cgi?id=2691
@@ -285,16 +324,18 @@
list->map = map;
down(&dev->struct_sem);
+ map->pub_handle = (map->type == _DRM_SHM
+ ? HandleID((unsigned long)map->handle,dev)
+ : HandleID(map->offset,dev));
list_add(&list->head, &dev->maplist->head);
up(&dev->struct_sem);
This conversion happens in HandleID().
Yes, pub_handle is unsigned long' and thus has the same size
as void *handle, but the value it contains is 32bit.
For userland the following patch takes care of a lot of
cases where an map handle is involved.
--- shared/drm.h 12 Apr 2005 17:46:45 -0000 1.1.1.1
+++ shared/drm.h 12 Apr 2005 17:48:19 -0000 1.1.1.2
@@ -126,7 +126,7 @@
#define _DRM_LOCKING_CONTEXT(lock) ((lock) & ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
-typedef unsigned long drm_handle_t; /**< To mapped regions */
+typedef unsigned int drm_handle_t; /**< To mapped regions */
typedef unsigned int drm_context_t; /**< GLXContext handle */
typedef unsigned int drm_drawable_t;
typedef unsigned int drm_magic_t; /**< Magic for authentication */
This should take care of all the instances where drm_handle_t is
used.
In the patches to the Xserver and the dri drivers I had to replace
a couple of 'unsigned long' with 'drm_handle_t'.
Also Alan came across the problem with drmAddress. This should
probably be changed to
typedef drm_handle_t drmAddress;
Non of the drivers that I looked at used drmAddress, though.
I'm not saying that I haven't missed anything. I have tested things
with three different drivers and I'm pretty sure I caught everything
that matters for these drivers.
Egbert.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
