Conversation

Someone should do this: DriverKit #WWDC19 🙂

Quote Tweet

Apr 17, 2019

Replying to @johnregehr @DanielMicay and 5 others

if I were someone like @ChadBrubaker5 I'd be trying like hell to get as many of these drivers as possible moved into user mode, since "rewrite 'em in a safe language" isn't viable in the short or medium term

Replying to

I linked developer.android.com/things/sdk/dri in that thread as an existing example on Android Things. That framework isn't currently used for drivers on Android for mobile devices, but many of the drivers are mostly implemented in userspace and got split into a bunch of sandboxes by Treble.

developer.android.com

Android Things | Android Developers

Build devices based on the Android Things platform.

Replying to

and

Can see this from a list of the processes: gist.github.com/thestinger/75e As an example, the Titan M driver has a tiny kernel driver (android.googlesource.com/kernel/msm/+/r), citadeld, hal_keymaster_citadel, hal_authsecret_citadel, hal_oemlock_citadel, hal_weaver_citadel. android.googlesource.com/platform/exter

gist.github.com

Stock Pixel 3a processes

GitHub Gist: instantly share code, notes, and snippets.

10:55 PM · Jun 3, 2019Twitter Web Client

Replying to

and

The android.hardware processes are the userspace components of the drivers implementing the stable versioned Treble ABIs. These are part of the vendor portion of the OS with the other hardware-specific services, etc. which is isolated from system with a stable ABI between them.

Replying to

and

For many drivers, most of the code and complexity already ends up in the userspace vendor portion rather than the kernel. Generic kernel drivers like Android Things / DriverKit helps take that further. By far the worst offender for kernel code size / complexity is Wi-Fi though.