Paul Mackerras writes: > > Haven't I mentined that it does? Handles that fit into 32bit > > should be handed to userspace unchanged, therefore if there is any > > code left that does arithmetic with these handles should continue > > to work. Handles that are used as real bases should be 32bit as > > these usually are pointer to base addresses. > > There is still a potential problem with your approach - if we are > going to create hashed 32-bit handles for 32-bit processes to use, we > have to create the hashed handles even if the addmap is being done by > a 64-bit process. The reason is that the X server passes handles to > DRI clients. If you have a 64-bit X server which does an addmap and > gets a 64-bit handle (which doesn't fit into 32 bits) and that handle > is then passed to a 32-bit client, the client won't be able to use > it because the 32-bit hashed version of the handle hasn't been > created. >
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 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
