On Fri, Sep 22, 2017 at 11:12 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > How would waiting help? Once P drops support for v7, all P userspaces (including containerized ones) need to be v8. After a while, the number of non-Android userspaces < P with v7 would become practically zero. But it's really hard to draw a line when it is "good enough", so I agree with you it doesn't really help, it just reduces the chance that somebody will be affected by it. > The relevant cases would seem to be: > > 1. updating a 32-bit Android Oreo (or earlier) OS from linux-4.9 > (or earlier) to linux-4.14 (or later) without updating libbinder: > This would require keeping around compile-time option > at least, for as long new kernels are supported on Oreo. I think it is unlikely a vendor would upgrade their kernel from linux-4.9 to linux-4.14 on an already launched Android device - it is just too much work. Vendors ideally should pick an LTS kernel and stick with it. But of course we can't rule it out. If it does happen, I don't think it would be strange to expect vendors to upgrade their userspace along with it. Many vendors (sadly) have a ton of patches on top of mainline, that may contain non-ABI-stable interfaces in the first place, and therefore would require a userspace push anyway. > 2. updating a 32-bit kernel to a 64-bit kernel on hardware > that allows this, without changing anything else: > Theoretically fixable, but this would require significant > code changes in the kernel module, similar to what I > described above. This is an issue independent of what we do here; if you used the v7 interface in your pre-4.14 32-bit kernel, you have to migrate to v8 simply because the v7 interface can't work with a (pre-4.14) 64-bit kernel. If you upgrade to a 4.14 kernel from which v7 is removed, you fall back to the previous case. Such a change would anyway require building and deploying a new Android userspace, assuming you'd want to allow running 64-bit userspace applications on such a kernel. I'm not sure whether there are good reasons to switch to a 64-bit kernel while maintaining a 32-bit only userspace. > What assumptions can we make about the two problematic > cases (1 and 2) here? Is it reasonable to require device > makes to always update libbinder together with the kernel? I personally think this is reasonable. Rolling out an update to an Android device involves a lot of work; if you're going to update the kernel, you'll often want to use the opportunity to update userspace as well for things like security fixes. Project Treble has made it significantly easier to update individual parts of Android. Unfortunately binder is so pervasive that it touches pretty much everything - migrating from v7 to v8 will require a full userspace push. Again, I don't think this is a problem, because: 1) Launched Android devices tend to stick with the kernel version they launched with (so v7 will stay available to them) 2) If they do want to upgrade, I don't think it's unreasonable to ask them to do a userspace push along with it 3) New devices launching with 4.14 (and P) will have no choice to use anything but v8 > Could that run into problems after a botched upgrade that > reverts back to an older kernel but keeps the new user space > or vice versa? Our current A/B partition scheme keeps a complete copy of both the old kernel and userspace when upgrading; if the upgrade doesn't boot, we revert both back to the old state. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
