5 ms·

It's quicker and easier than submitting any patches upstream. They don't care about support past product release. Usually the SoC vendor provides the forked ve

It's quicker and easier than submitting any patches upstream. They don't care about support past product release. Usually the SoC vendor provides the forked version, and the manufacturer forks that again, so they are twice removed from upstream. If they ever upgrade Android versions, they port all of their patches onto a new fork from the SoC vendor.

euyyn 10y ago
The question is not "why don't they upstream the changes". Rather why do they have to fork to achieve what they need.
- kbenson 10y ago
  Because kernel developers can only work with what they're given. If the hardware isn't supplied by the company or some grant, or if it's IP encumbered, then you have a situation where it's unlikely to be supported natively by the kernel. At that point, it becomes a short-term or long-term benefit assessment. Long-term, it's better to work to get it accepted upstream, but that's more work in that you have to make sure your patch is acceptable and conforms to how the kernel devs want it, and they can verify the support works, instead of just working as you've set up in-house. With the rush to market, and with the specific configuration of chips possibly not being used in the next item released, short-term patches likely look really attractive.
  - euyyn 10y ago
    I don't think I'm explaining myself well. Can't the kernel be modified so that manufacturer-specific code can stay in-house? Let me give you an example: I don't need to fork my text editor to make it highlight and autocomplete any new programming language I invent myself. And I don't need to give the editor developers anything to work with either. Because they've put the needed hooks and interfaces in place for me to write my stuff without having to modify theirs.
    - rogerbinns 10y ago
      > I don't think I'm explaining myself well. Can't the kernel be modified so that manufacturer-specific code can stay in-house? The kernel is under the GPLv2 so redistributing kernel binaries also requires making source available (that is all part of the "freedom"). The kernel internals constantly change. For example the USB stack was rewritten 4 times. Each time all the drivers etc were converted over. By contrast Microsoft has also rewritten their stack 4 times, but has to retain backwards compatibility for each generation of driver API/ABI, simultaneously! While in theory it is possible to have a stable API, in practise real life is more complicated. There are concurrency issues, power management, suspend/resume, memory allocation, constantly changing hardware etc. A stable API would result in way less optimal drivers (eg they may consume more memory or power, cause cores to run at higher speeds). The kernel developers decided they weren't going to have that layer of indirection. Instead drivers will do the one true correct thing (updated as kernel versions change). That makes them simpler, and perform better in the dimensions mentioned in the previous paragraph. That all said, Linux is fanatical about the userspace API to the kernel being stable. You can implement drivers (eg USB) and filesystems (eg FUSE) amongst other things in userspace. However they won't be as "good" as kernel drivers. Here is a good post from a kernel developer: http://www.kroah.com/log/linux/stable_api_nonsense.html http://www.kroah.com/log/linux/stable_api_nonsense.html To get an idea of what changes in the kernel, check out the LWN page. If you have interest in Linux, I'd recommend subscribing too. https://lwn.net/Kernel/ https://lwn.net/Kernel/
      - euyyn 10y ago
        Thank you for the explanation and the link to that article. I disagree with some of the philosophical statements, like: > While in theory it is possible to have a stable API, in practice real life is more complicated. (In practice it's also possible, as Microsoft demonstrated with Windows for decades). or (from the article): > benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place (The reality is, that wasn't enough of a reason to move users from Windows, before the smartphone era. Nor is it the reason Linux won over Windows in the smartphone market, either.) I think the article hits the crux of the issue, though: Nobody wants to spend their free time contributing to maintain an old interface, instead of working on the new one. A side effect of this policy is a better kernel, granted (for the devices that actually make it to the main tree). So given that a stable API isn't an option, and the current model is clearly not working, I guess the solution lies in solving the hurdles these companies face to upstream their code. Do you know about that, or where could I learn more?
- zanny 10y ago
  The shit disasters vendors force into their forks would never be accepted mainline, and even if they would be, these vendors take the route of most control - working with anyone else would violate their own ego that they always know best, so they never work with anyone else.

euyyn 10y ago

The question is not "why don't they upstream the changes". Rather why do they have to fork to achieve what they need.

kbenson 10y ago
Because kernel developers can only work with what they're given. If the hardware isn't supplied by the company or some grant, or if it's IP encumbered, then you have a situation where it's unlikely to be supported natively by the kernel. At that point, it becomes a short-term or long-term benefit assessment. Long-term, it's better to work to get it accepted upstream, but that's more work in that you have to make sure your patch is acceptable and conforms to how the kernel devs want it, and they can verify the support works, instead of just working as you've set up in-house. With the rush to market, and with the specific configuration of chips possibly not being used in the next item released, short-term patches likely look really attractive.
- euyyn 10y ago
  I don't think I'm explaining myself well. Can't the kernel be modified so that manufacturer-specific code can stay in-house? Let me give you an example: I don't need to fork my text editor to make it highlight and autocomplete any new programming language I invent myself. And I don't need to give the editor developers anything to work with either. Because they've put the needed hooks and interfaces in place for me to write my stuff without having to modify theirs.
  - rogerbinns 10y ago
    > I don't think I'm explaining myself well. Can't the kernel be modified so that manufacturer-specific code can stay in-house? The kernel is under the GPLv2 so redistributing kernel binaries also requires making source available (that is all part of the "freedom"). The kernel internals constantly change. For example the USB stack was rewritten 4 times. Each time all the drivers etc were converted over. By contrast Microsoft has also rewritten their stack 4 times, but has to retain backwards compatibility for each generation of driver API/ABI, simultaneously! While in theory it is possible to have a stable API, in practise real life is more complicated. There are concurrency issues, power management, suspend/resume, memory allocation, constantly changing hardware etc. A stable API would result in way less optimal drivers (eg they may consume more memory or power, cause cores to run at higher speeds). The kernel developers decided they weren't going to have that layer of indirection. Instead drivers will do the one true correct thing (updated as kernel versions change). That makes them simpler, and perform better in the dimensions mentioned in the previous paragraph. That all said, Linux is fanatical about the userspace API to the kernel being stable. You can implement drivers (eg USB) and filesystems (eg FUSE) amongst other things in userspace. However they won't be as "good" as kernel drivers. Here is a good post from a kernel developer: http://www.kroah.com/log/linux/stable_api_nonsense.html http://www.kroah.com/log/linux/stable_api_nonsense.html To get an idea of what changes in the kernel, check out the LWN page. If you have interest in Linux, I'd recommend subscribing too. https://lwn.net/Kernel/ https://lwn.net/Kernel/
    - euyyn 10y ago
      Thank you for the explanation and the link to that article. I disagree with some of the philosophical statements, like: > While in theory it is possible to have a stable API, in practice real life is more complicated. (In practice it's also possible, as Microsoft demonstrated with Windows for decades). or (from the article): > benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place (The reality is, that wasn't enough of a reason to move users from Windows, before the smartphone era. Nor is it the reason Linux won over Windows in the smartphone market, either.) I think the article hits the crux of the issue, though: Nobody wants to spend their free time contributing to maintain an old interface, instead of working on the new one. A side effect of this policy is a better kernel, granted (for the devices that actually make it to the main tree). So given that a stable API isn't an option, and the current model is clearly not working, I guess the solution lies in solving the hurdles these companies face to upstream their code. Do you know about that, or where could I learn more?
zanny 10y ago
The shit disasters vendors force into their forks would never be accepted mainline, and even if they would be, these vendors take the route of most control - working with anyone else would violate their own ego that they always know best, so they never work with anyone else.