5 ms·

It's a stretch to call these "Linux-based" phones. The kernel [1] comes from an old Android fork of Linux 3.10 which is nearly 6 years old. Android kernel cod

by wicket 8y ago

It's a stretch to call these "Linux-based" phones. The kernel [1] comes from an old Android fork of Linux 3.10 which is nearly 6 years old. Android kernel code is largely incompatible with mainline Linux which is the reason there are very few phones that can run actually run mainline (real) Linux. [1] https://github.com/kaiostech/kernel_msm-3.10 https://github.com/kaiostech/kernel_msm-3.10

Bayart 8y ago
>which is the reason there are very few phones that can run actually run mainline (real) Linux. You mean the drivers not being in the Linux Kernel/hard to port ? because I have a very hard time believing most smartphones couldn't run the Linux kernel, provided it's compiled to whatever architecture and the drivers are there.
- pjmlp 8y ago
  Android Linux is quite different from upstream Linux, specially after Project Treble. Now it looks more like a pseudo-mikrokernel, with drivers running on their own processes, talking via Android IPC with the kernel layer. Also it has a much more security knobs turned on as mainline, and many features trimmed down that are irrelevant to Android userspace.
  - stefan_ 8y ago
    Treble is just another layer of abstraction on top of HALs and more binder use. Android HALs don't replace kernel drivers and so it's still the same distance from mikrokernel as it ever was, and neither did Treble further the split from mainline Linux. If anything, Android 8 reduced the gap to mainline with switching e.g. to DRM synchronization fences.
    - pjmlp 8y ago
      Reading through AOSP documentation and AOSP source code tells another story. > Binderized HALs. HALs expressed in HAL interface definition language (HIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only. > > Passthrough HALs. A HIDL-wrapped conventional or legacy HAL. These HALs wrap existing HALs and can serve the HAL in binderized and same-process (passthrough) modes. Devices upgrading to Android 8.0 can use passthrough HALs. > All other HALs provided by the vendor image can be in passthrough OR binderized mode. In a fully Treble-compliant device, all of these must be binderized. > Legacy HALs (also deprecated in Android 8.0) are interfaces that predate conventional HALs. A few important subsystems (Wi-Fi, Radio Interface Layer, and Bluetooth) are legacy HALs. While there's no uniform or standardized way to describe a legacy HAL, anything predating Android 8.0 that is not a conventional HAL is a legacy HAL. Parts of some legacy HALs are contained in libhardware_legacy, while other parts are interspersed throughout the codebase. https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types A binderized HAL driver only requires a minimal kernel surface, if anything. Furthermore, I specifically stated pseudo on my description.
      - stefan_ 8y ago
        Nothing you quoted changes anything. Yes, they added more abstraction on top of HALs. No, that doesn't mean HALs are now any "closer to the metal" than before. Here are some obvious hints to why this is not true: * there are no HALs defined for even 1/3rd of what kernel drivers you would need to run a modern device * a bunch of the HALs require you to provide handles obtained from standardized kernel interfaces (e.g. the aforementioned sync objects) Finally, of course: all HALs run in userland! All their power is in being granted SELinux access to various kernel interfaces! Vendors can not change these rules or risk failing certification.
        pjmlp 8y ago
        > > Legacy HALs (also deprecated in Android 8.0) are interfaces that predate conventional HALs. A few important subsystems (Wi-Fi, Radio Interface Layer, and Bluetooth) are legacy HALs.
- wicket 8y ago
  Android kernels are forked up to six times [1] which results in kernels that have diverged significantly from mainline. Mainlining a device is no way near as trivial a task as you make it out to be. Have a look at how many Android mobile phones have a least bare minimal mainline Linux support [2][3], then have a look at postmarketOS's mainlining guide [4] and you'll get some idea. [1] https://source.android.com/devices/architecture/kernel/android-common#branch-hierarchy https://source.android.com/devices/architecture/kernel/andro... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [4] https://wiki.postmarketos.org/wiki/Mainlining_Guide https://wiki.postmarketos.org/wiki/Mainlining_Guide

by wicket 8y ago

Bayart 8y ago

>which is the reason there are very few phones that can run actually run mainline (real) Linux. You mean the drivers not being in the Linux Kernel/hard to port ? because I have a very hard time believing most smartphones couldn't run the Linux kernel, provided it's compiled to whatever architecture and the drivers are there.

pjmlp 8y ago
Android Linux is quite different from upstream Linux, specially after Project Treble. Now it looks more like a pseudo-mikrokernel, with drivers running on their own processes, talking via Android IPC with the kernel layer. Also it has a much more security knobs turned on as mainline, and many features trimmed down that are irrelevant to Android userspace.
- stefan_ 8y ago
  Treble is just another layer of abstraction on top of HALs and more binder use. Android HALs don't replace kernel drivers and so it's still the same distance from mikrokernel as it ever was, and neither did Treble further the split from mainline Linux. If anything, Android 8 reduced the gap to mainline with switching e.g. to DRM synchronization fences.
  - pjmlp 8y ago
    Reading through AOSP documentation and AOSP source code tells another story. > Binderized HALs. HALs expressed in HAL interface definition language (HIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later must support binderized HALs only. > > Passthrough HALs. A HIDL-wrapped conventional or legacy HAL. These HALs wrap existing HALs and can serve the HAL in binderized and same-process (passthrough) modes. Devices upgrading to Android 8.0 can use passthrough HALs. > All other HALs provided by the vendor image can be in passthrough OR binderized mode. In a fully Treble-compliant device, all of these must be binderized. > Legacy HALs (also deprecated in Android 8.0) are interfaces that predate conventional HALs. A few important subsystems (Wi-Fi, Radio Interface Layer, and Bluetooth) are legacy HALs. While there's no uniform or standardized way to describe a legacy HAL, anything predating Android 8.0 that is not a conventional HAL is a legacy HAL. Parts of some legacy HALs are contained in libhardware_legacy, while other parts are interspersed throughout the codebase. https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types A binderized HAL driver only requires a minimal kernel surface, if anything. Furthermore, I specifically stated pseudo on my description.
    - stefan_ 8y ago
      Nothing you quoted changes anything. Yes, they added more abstraction on top of HALs. No, that doesn't mean HALs are now any "closer to the metal" than before. Here are some obvious hints to why this is not true: * there are no HALs defined for even 1/3rd of what kernel drivers you would need to run a modern device * a bunch of the HALs require you to provide handles obtained from standardized kernel interfaces (e.g. the aforementioned sync objects) Finally, of course: all HALs run in userland! All their power is in being granted SELinux access to various kernel interfaces! Vendors can not change these rules or risk failing certification.
      - pjmlp 8y ago
        > > Legacy HALs (also deprecated in Android 8.0) are interfaces that predate conventional HALs. A few important subsystems (Wi-Fi, Radio Interface Layer, and Bluetooth) are legacy HALs.
wicket 8y ago
Android kernels are forked up to six times [1] which results in kernels that have diverged significantly from mainline. Mainlining a device is no way near as trivial a task as you make it out to be. Have a look at how many Android mobile phones have a least bare minimal mainline Linux support [2][3], then have a look at postmarketOS's mainlining guide [4] and you'll get some idea. [1] https://source.android.com/devices/architecture/kernel/android-common#branch-hierarchy https://source.android.com/devices/architecture/kernel/andro... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [4] https://wiki.postmarketos.org/wiki/Mainlining_Guide https://wiki.postmarketos.org/wiki/Mainlining_Guide