Egbert Eich writes: > That's fine. If somone tells me what needs to be done > I'm happy to change this. > I've been carrying this code along for too long now. > When I started this this kind of conversion functions > didn't exist.
Is there anything wrong with the code that is currently in the kernel, other than the fact that you didn't write it? > > Also, does a kernel with your patch work with existing unmodified X > > servers and DRI clients? On x86_64 that would mean a 64-bit X server > > with 64-bit clients. Or do you require userspace to be updated if the > > kernel DRM is updated with your patch? > > 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. Paul. ------------------------------------------------------- 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
