4 ms·

I don't see a microkernel architecture here. Requiring drivers to be loadable modules is just arriving in the 1990s of monolithic kernels. Also, only new device

I don't see a microkernel architecture here. Requiring drivers to be loadable modules is just arriving in the 1990s of monolithic kernels. Also, only new devices with SoCs introduced for Android 9 are required to use kernel modules and kernels newer than 3.18. [1] This means most (updated) Android 8 devices in the field are not Project Treble and are running old-style module-less kernels and don't have A/B system partitions. HALs only seem to be there to abstract over the APIs of different hardware implementations and access to them. Not necessarily their drivers. I would love to be wrong about this, so I would really appreciate evidence to the contrary here. [1] https://source.android.com/devices/architecture/kernel/modular-kernels#kernel-version https://source.android.com/devices/architecture/kernel/modul...

pjmlp 8y ago
Because you just stopped at the kernel modules part and haven't spent time reading how HAL in Android actually works, starting at the HIDL link. There are two HALs in Android. The old HAL, previous to Treble, which was hardly used by OEMs. And the new HAL, which is enforced by Treble. On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shared memory APIs introduced in Oreo as well. https://source.android.com/devices/architecture/hidl/services https://source.android.com/devices/architecture/hidl/service... https://source.android.com/devices/architecture/hidl/binder-ipc https://source.android.com/devices/architecture/hidl/binder-... https://source.android.com/devices/architecture/hidl/memoryblock https://source.android.com/devices/architecture/hidl/memoryb... https://source.android.com/devices/architecture/configstore/ https://source.android.com/devices/architecture/configstore/
- scintill76 8y ago
  I'll admit to not being steeped in the terminology, so feel free to educate me.. but some quick Googling suggests nobody else has called Treble a "microkernel." There are hits about Fuchsia (a totally separate OS), and some Android forks on microkernels. I'm guessing that the Treble modules expose the traditional /dev and /sys interfaces like before, and these new HALs talk to devices through those, right? Is that not still a runtime-linked monolith, with fairly-thin userspace services between the kernel and the framework? The bulk of driver code logic (e.g. interfacing with a touchscreen controller) is probably still running in the kernel - show me if I'm wrong. I would think this would be how you define a microkernel. One exception may be the GPU -- those drivers are often very thin in the kernel because of GPL, with a fat userspace library that they can legally keep closed-source.
  - pjmlp 8y ago
    They use Android IPC, which is a kind of RPC between processes. https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types
  - ysleepy 8y ago
    This is exactly how I understand it.
- ysleepy 8y ago
  I actually looked into the HAL/HIDL docs before posting and found no evidence that they are there to implement drivers in userspace. As I understand it HALs and HIDL are used to provide a standardized way to implement new device features in a compatible way. So a vendor introduces a odor-sensor and can define an HIDL interface for the userspace to call the device driver provided in a kernel module. I do not see a requirement to implement drivers in userspace, nor provisions for it, like interrupt handling, i2c/spi access or similar.
  - pjmlp 8y ago
    HIDL is the basis of Android IPC between processes, known as Binder. "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. " https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types Here are the user space driver APIs for i2c/spi access on Android Things. https://developer.android.com/reference/com/google/android/things/pio/package-summary https://developer.android.com/reference/com/google/android/t...
    - monocasa 8y ago
      Binder allows for endpoints in kernel space.
      - pjmlp 8y ago
        Of course, otherwise how would they support passthrough legacy HALs for devices upgrading to Oreo as described on the documentation? Interprocess RPC is only for Oreo and newer.
        8y ago

pjmlp 8y ago

Because you just stopped at the kernel modules part and haven't spent time reading how HAL in Android actually works, starting at the HIDL link. There are two HALs in Android. The old HAL, previous to Treble, which was hardly used by OEMs. And the new HAL, which is enforced by Treble. On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shared memory APIs introduced in Oreo as well. https://source.android.com/devices/architecture/hidl/services https://source.android.com/devices/architecture/hidl/service... https://source.android.com/devices/architecture/hidl/binder-ipc https://source.android.com/devices/architecture/hidl/binder-... https://source.android.com/devices/architecture/hidl/memoryblock https://source.android.com/devices/architecture/hidl/memoryb... https://source.android.com/devices/architecture/configstore/ https://source.android.com/devices/architecture/configstore/

scintill76 8y ago
I'll admit to not being steeped in the terminology, so feel free to educate me.. but some quick Googling suggests nobody else has called Treble a "microkernel." There are hits about Fuchsia (a totally separate OS), and some Android forks on microkernels. I'm guessing that the Treble modules expose the traditional /dev and /sys interfaces like before, and these new HALs talk to devices through those, right? Is that not still a runtime-linked monolith, with fairly-thin userspace services between the kernel and the framework? The bulk of driver code logic (e.g. interfacing with a touchscreen controller) is probably still running in the kernel - show me if I'm wrong. I would think this would be how you define a microkernel. One exception may be the GPU -- those drivers are often very thin in the kernel because of GPL, with a fat userspace library that they can legally keep closed-source.
- pjmlp 8y ago
  They use Android IPC, which is a kind of RPC between processes. https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types
- ysleepy 8y ago
  This is exactly how I understand it.
ysleepy 8y ago
I actually looked into the HAL/HIDL docs before posting and found no evidence that they are there to implement drivers in userspace. As I understand it HALs and HIDL are used to provide a standardized way to implement new device features in a compatible way. So a vendor introduces a odor-sensor and can define an HIDL interface for the userspace to call the device driver provided in a kernel module. I do not see a requirement to implement drivers in userspace, nor provisions for it, like interrupt handling, i2c/spi access or similar.
- pjmlp 8y ago
  HIDL is the basis of Android IPC between processes, known as Binder. "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. " https://source.android.com/devices/architecture/hal-types https://source.android.com/devices/architecture/hal-types Here are the user space driver APIs for i2c/spi access on Android Things. https://developer.android.com/reference/com/google/android/things/pio/package-summary https://developer.android.com/reference/com/google/android/t...
  - monocasa 8y ago
    Binder allows for endpoints in kernel space.
    - pjmlp 8y ago
      Of course, otherwise how would they support passthrough legacy HALs for devices upgrading to Oreo as described on the documentation? Interprocess RPC is only for Oreo and newer.
      - 8y ago