From: Dave Airlie <airl...@gmail.com>
Date: Wed, 28 Oct 2009 13:28:10 +1000

> On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen <a...@firstfloor.org> wrote:
>> On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
>>> We've designed that into a/c also, we pad all 64-bit values to 64-bit
>>> alignment on all the
>>> ioctls we've added to the drm in the past couple of years. Just because of
>>> this particular insanity.
>>
>> That's actually not needed, just use compat_*64.
>>>
>>> Assume no mistakes are made, new ioctls designed from scratch
>>
>> That seems like a bad assumption. It sounds like you already
>> made some.
> 
> You mean its impossible to design a 32/64-bit safe ioctl no matter what?

If you use pointers at all, yes.  We've said this several times.

> and we should live with having compat ioctls? This isn't something that was 
> very
> clearly stated or documented, the advice we had previously was that
> compat ioctls
> were only required for old ioctls or ioctls with design problems. compat_*64
> didn't exist when this code we designed, and we worked around that, but it was
> in no way mistaken, manually aligning 64-bit values is a perfectly
> good solution,
> not sure why you imply it isn't.

Manually "aligning" the way you have solves only one side of the
compat problem on x86 with 64-bit types.  It may handle the layout
properly bit it doesn't change the alignment requirements of the
containing structure and that's a similarly important the issue.

If you want to solve both aspects, use the "aligned_u64" type.

But once you introduce pointers, you must have compat layer code,
and this is a hard requirement.  And there is nothing baroque or
wrong about it.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to