Russell King as recently as 2009 was against it. It got merged around ~2013 so it took about 4 years. The first Android phone was supposed to be 2009 but IIRC it got delayed to 2010 because of the iPhone (announced 2008). I think my characterization of this is fair and accurate.
> Well, for one thing you have only one ABI to consider if you go with the LTS instead of hundreds we have today.
I don't follow. You have 1 Android release per year. There is a new LTS kernel every year. I don't see how sticking to LTS solves the problem. You have to actively hold off on Linux kernel releases to get any advantage of this process. For something like Android this means they'd be forking LTS & it would be even more work to move to a new kernel (all the out-of-tree development + all your driver vendors switching kernels). So now you'd be complaining why Android is using such an ancient Android kernel. Treble solves a real problem and has nothing to do with NIH unless you just define all kernel development happening at Google as NIH (which would be strange considering how many Linux kernel developers and maintainers they employ).
Russell King as recently as 2009 was against it. It got merged around ~2013 so it took about 4 years. The first Android phone was supposed to be 2009 but IIRC it got delayed to 2010 because of the iPhone (announced 2008). I think my characterization of this is fair and accurate.
> Well, for one thing you have only one ABI to consider if you go with the LTS instead of hundreds we have today.
I don't follow. You have 1 Android release per year. There is a new LTS kernel every year. I don't see how sticking to LTS solves the problem. You have to actively hold off on Linux kernel releases to get any advantage of this process. For something like Android this means they'd be forking LTS & it would be even more work to move to a new kernel (all the out-of-tree development + all your driver vendors switching kernels). So now you'd be complaining why Android is using such an ancient Android kernel. Treble solves a real problem and has nothing to do with NIH unless you just define all kernel development happening at Google as NIH (which would be strange considering how many Linux kernel developers and maintainers they employ).