I'm trying to remember why Android forked from Linux in the first place. Or was it always it's own thing?
My memory was maintainers on the linux side had an issue with wakelocks maybe?
At one point google going to some pretty serious lengths to try to integrate / upstream some stuff and it getting totally shot down.
My own view was there was a bit of a missed opportunity there
Wakelocks and allocation of physically contiguous memory allocations (ashmem, dumped now in favor of dmabuff). All upstreamed now.
At this point, Androids kernel is only a fork of upstream Linux kernel because Google employs so many kernel devs that some features are developed downstream first, then upstreamed once kinks are worked out after shipping in devices on tighter deadlines than upstream.
> allocation of physically contiguous memory allocations (ashmem, dumped now in favor of dmabuff).
ashmem is user space shared memory with permission controls. It was replaced(ish) with memfd with the addition of F_SEAL_FUTURE_WRITE in 5.1 (it took a shockingly long time for that to finally have feature parity but hey better late than never)
ION is the special allocator that was replaced with dmabuf.
Also ARM, qcom, etc... all love playing with the scheduler or making other changes which typically happens downstream first for time-to-market reasons before being upstreamed. eg, ARM's EAS / energy aware scheduling I think actually shipped to users prior to upstream accepting it.
Did the maintainer change on linux side to make linux more comfortable with the stuff coming from android? It felt like back in the days there was a real resistance on the linux side - even though the linux "solutions" where more theoretical.
The way I understood it from the Android history books, it's mostly that the Android team (after some initial attempts) didn't want to spend time with Linux kernel drama because they had to ship the OS in a rush. So it was just easier to fork the kernel and ship it in a state that doesn't require upstream approval.
Linux at that time was very much unequipped at handling low power devices well (e.g. Wakelocks have already been mentioned).
Right - that was my memory. My memory of this was just wondering, what / where is linux actually shipping on low power / power managed devices that they have such a strong view against wakelocks. Code talk and talk walks - and I felt at the time there was a lot of theoretically better approaches being pitched by Linux but nothing was concrete or close to shipping. Can totally understand that at some point google just couldn't wait for the bikeshedding to finish given the push to get to market with stuff.
That’s certainly how it seemed from the Android side at the time. The Linux side was hoping that they could adapt the desktop Linux stack to work well on mobile devices, without introducing new concepts like wakelocks. It took them a long time to give up on that approach.
My memory was maintainers on the linux side had an issue with wakelocks maybe? At one point google going to some pretty serious lengths to try to integrate / upstream some stuff and it getting totally shot down.
My own view was there was a bit of a missed opportunity there