4 ms·
In that case it wouldn't have replaced Android at all -- It would have simply replaced the Android kernel, which happens to be Linux. And at that point you have
by endorphone 8y ago
In that case it wouldn't have replaced Android at all -- It would have simply replaced the Android kernel, which happens to be Linux. And at that point you have to ask what is gained, and at this point the answer is "nothing".
- monocasa 8y agoWell a change of the kernel's license from GPLv2 to BSD is certainly a change. I'm sure the OEMs think that gains them something.
- endorphone 8y agoAndroid OEMs are not in the business of writing kernels, though, and the changes they do are minimal. And their HAL/chipset code -- the thing they might actually care about as IP -- is not governed by the GPL at all, nor is any of the enormous volume of system and userspace code they write. It's a neat initiative and might yield something interesting, but if the Linux kernel was replaced by Fuscia the ramifications are seemingly very minor. Android's many issues have never been at the kernel level.
- monocasa 8y agoThe components of their HAL/chipset code in the kernel are most of the time governed by the GPL. We can take some examples apart of need be.
- pjmlp 8y agoAfter Project Treble that only applies to the legacy HAL code.
- monocasa 8y agoEven fully after Treble, there are absolutely still kernel drivers.
- pjmlp 8y agoSure there are, they are known as "legacy HALs" on Project Treble documentation.
- monocasa 8y agoLiterally any driver that has a piece that runs in interrupt context has to have (in part) a kernel mode driver under Linux. On top of that, GPUs generally have to have a kernel component, even under systems that put as much as possible under user mode like sel4, because they have their own MMUs that can subvert kernel integrity.
- pjmlp 8y agoAgain, yes there are drivers running in the kernel space, yes they are mostly GPL, no Google isn't re-writing them into Binderized HALs, they can stay as Passthrough HALs. Nothing of that prevents that all new drivers, except for the ones marked as legacy, are required to be Binderized. The kernel code of a driver from OEMs allergic to GPL, is hardly different from a signal handler, implementing the minimal set of kernel code and deferring everything else to userspace.
- monocasa 8y agoSort of... I'm going to go out on a limb here and guess that you don't actually write kernel drivers like I do professionally.
- wolfgke 8y ago> And at that point you have to ask what is gained, and at this point the answer is "nothing". Not having to care about the permanent breaking of internal kernel APIs is not "nothing".
- endorphone 8y agoHow, exactly, will they "not have to care"? The identical ramifications occur with Fuscia as they happen with Linux! This is farce. Every single problem that Android has had, from low-latency audio issues (they've rebuilt that a dozen times in a dozen cartoonish ways) to driver stagnancy, is completely and directly a result of Google choices and implementations (and they do the same thing again and again! It's remarkable). The notion that Google is going to fix all of their own self-sabotage by starting anew is comedic in a sense, and is the folly of countless foolish projects. "We keep fucking up again and again...let's start from scratch and this time we'll surely do it right!" This time, however, it'll be different...
- wolfgke 8y agoIt is a difference whether the fault for this lies at the Google engineers or the kernel maintainers.
- endorphone 8y agoGoogle has never been required to commit upstream, but they've chosen to do so because of the ease of integrating changes downstream. They could have forked off and bashed the code into whatever form they wanted to. Breaking anything and everything. But they didn't. They kept keeping it in sync. They probably had a reason for doing that.
- pjmlp 8y agoGoogle has chosen to cherry pick commits to upstream, there is still plenty of stuff on AOSP, and much more on internal Googleplex repos.