Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=943
------- Additional Comments From [EMAIL PROTECTED] 2005-04-13 07:06 -------
One could do a conversion - on the other hand a brakage of the ABI compatibility
between client and Xserver would not be all that bad - given that we cannot
really distinguish if a 32bit client library contains code that fixes the size
or not.
The main issue that I ran into was the size of drm_handle_t which I changed from
'long' to 'int'. It's defined in the drm headers however the drm modules don't
seem to use it at all.
It ensures that the same handles are used in 32 and 64bit and can be exchanged
between 32 and 64bit pieces. This is done between the Xserver and 32bit clients.
This however requires that 32 and 64bit both return 32bit handles. This may be
the reason why my code is more intrusive.
Apart from this of all the drivers I fixed I only saw an issue with Matrox.
> On the DRM portion can you look at the work Paul has done, it is much cleaner
> and less intrusive, you are also using the old method which is deprecated now
> > in
> the kernel, the new method is available in Pauls patch in the -mm kernel,
> maybe
> Paul can generate a patch against 2.6.11....
The kernel ABI really hasn't changed. The ioctls have remained the same. The
only change I've made was to make sure the handles passed between kernel and
user space fit into 32bit.
That means that they are not necessarily real offset values any more. If
anything needs real offset values it needs to obtain it thru another way. If fit
in 32bits my code attempts to reuse them. If they are 64bit however a 32bit hash
is created. It is also make sure that the handles are unique.
For your argument about intrusiveness please see above.
I'm presently reworking my driver to support both the old and the new method.
My intention was to make the creation of 32bit ioctls as boiler plate as
possible. My hope was that this would encourage people to provide compat support
for every driver.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
