On Wed, Dec 11, 2013 at 10:10 AM, Octavian Purdila <octavian.purdila@xxxxxxxxx> wrote: > On Wed, Dec 11, 2013 at 5:21 AM, Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote: >> >> Assuming you are talking about a kernel compat layer that translates >> the flat_binder_object structs as they pass between 32 bit and 64 bit >> processes, that will not always work. The data portion of the message >> sometimes contain size values that are invisible to the kernel, but >> these values will be wrong if the kernel move data to make room for a >> different size flat_binder_object. >> > > Hi Arve, > > Yes, I was talking about translating flat_binder_objects. > > I understand the potential issue for the user data payload, however, > since most applications will use libbinder, the only problematic case > is readIntPtr/writeIntPtr, which we can deprecate and convert > applications that use it to readInt64. AFAICS there is only one user > in the AOSP for this API (libmedia). > > If you are referring to data blobs that application parses I don't > think there is anything we can do, even at libbinder level. > > Can you give me an example of the sort of problems you see? > > Thanks, > Tavi The specific problem I was told about can be found in frameworks/base/core/java/android/os/Bundle.java, but there could be other. The size of the bundle is stored in the parcel so the end of the bundle will be wrong if the bundle contains a flat_binder_object that the driver changes the size of. However, since the sending process gets the parcel size from libbinder, changing libbinder to always use the 64 bit version of flat_binder_object should work with this code. -- Arve Hjønnevåg _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
