Problem with framebuffer mmap on platforms with large addressing

[Florian Tobias Schandinat]

On 03/19/2012 02:42 PM, Dmitry Eremin-Solenikov wrote:
> On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
>> On Sun, 2012-03-18 at 18:04 +0400, Dmitry Eremin-Solenikov wrote:
>>> On Sun, Mar 18, 2012 at 4:46 AM, Benjamin Herrenschmidt
>>> <benh at kernel.crashing.org> wrote:
>>>> 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