On 03/19/2012 02:42 PM, Dmitry Eremin-Solenikov wrote:

On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:

quoted

On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

In fact, we could make the new structure such that it doesn't break
userspace compatibility with 64-bit architectures at all, ie, the "new"
and "compat" ioctl could remain entirely equivalent on 64-bit.

I remember stuff about compat_ioctl, but I have never used/implemented
that. Are there any details of requirements for the structures being passed?

In that specific case, I meant something else. IE. The old ioctl could
remain unchanged, and the new ioctl make the same as the old one on
64-bit platforms.

I don't think this kind of magic would be good. I'd just stick to the new
ioctl.

I finally found where we started to discuss this issue, for reference
"sm501fb.c: support mmap on PPC440SPe/PPC440EPx" back in May 2010.

The thing I don't remember is why we consider exporting the physical
address to userspace desirable (or even necessary). Fixing the generic
mmap would be trivial without breaking or adding any userspace ABI, I
think. Just adding those things to fb_info and adjusting fb_mmap should
do the trick, shouldn't it?


Best regards,

Florian Tobias Schandinat