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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
