On 03/19/2012 02:42 PM, Dmitry Eremin-Solenikov wrote: > On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt > <benh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
