Re: 32/64-bit ioctl compatibility

[Shrijeet M. <sh...@sg...>]

> > Changing the drm and Mesa at once incompatibly isn't going to get past me,
> > and I haven't proven that Egberts patch isn't backwards compat, but nobody
> > has proven to me that it doesn't break anything, and as I have no access
> > to any 64-bit hardware it is up to other people to convince me ...
> 
> The hardest bit that I have seen so far is dealing with the offset and
> handle fields in the drm_map_t.  I'll push on it a bit further then,
> if no-one else is hacking on this.

This is a topic that we could use some clarification on, is there a
"suggested" use for offset and handle. As you can imagine we(SGI) with
our itanium systems have to deal with this a fair bit.

My interpretation is that handle is a unique opaque identifier to a drm
resource on the board (which needs to match the native word size of the
platform you are running on, or unique is hard to guarantee)

OTOH, offset is a value that the board manager (normally in the 2D
driver in the current X setup) uses to setup/access said resources. This
needs to be of the size of the bus width of the card.

If this is correct, it brings up another interesting issue. How do we
pass to the mmap calls 64-bit OS offsets when the actual offset (for all
current gfx cards I know of) is a 32-bit entity, which brings up the
reverse option to what was suggested .. should we just pass the handle
instead of the offset, since that already is a kernel virtual address
that linux wants. (this should work on linux platforms atleast)