On 03/19/2012 02:42 PM, Dmitry Eremin-Solenikov wrote: > On Mon, Mar 19, 2012 at 12:49 AM, Benjamin Herrenschmidt > <b...@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 >>> <b...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
