|Android MC 2019 Progress Report|
|Sandeep||Generic Kernel Image (GKI) progress|
|Matthias||Monitoring and Stabilizing the In-Kernel ABI||General interest in mechanisms to stabilize the in-kernel ABI. Multiple parties seem interested to collaborate on this.||Scepticism about: |
- What symbols to cover (observable, whitelist, namespaces).
- To what extent, API can be covered by ABI checks.
Expressed interest for a _working_ runtime check (fix modversions).
|Saravana||Solving issues associated with modules and supplier-consumer dependencies||Overall, the of_devlink series was well received. DT and driver core maintainers were mostly happy with the patches. Regulator and GPIO maintainers raised some questions but were in general okay with the idea||- Work needed for adding support for other common DT bindings.|
- Question was raised how we plan to handle non-generic dependencies (Eg: camera/media pipeline). No great answer. Pointed out that a "depends-on" binding was proposed early on, but wasn't well received by DT maintainers.
|Alistair||Android Virtualization (esp. Camera, DRM)||Interest in working on upstream virtio driver for gpio. Support of virtio strategy for Android emulation|
|Laurent||libcamera: Unifying camera support on all Linux systems||libcamera is a candidate to implement the host side of camera virtualisation for Cuttlefish.||- libcamera is licensed under the LGPL-2.0+ to avoid closed-source vendor forks. Find out how to handle Android license requirements.|
- Start discussions with the Android camera team to exchange feedbacks on libcamera and the Android camera HAL.
|Daniel||Emulated storage features (eg sdcardfs)|
|Ashish||Eliminating WrapFS hackery in Android with ExtFUSE (eBPF/FUSE)|
|Maze||How we're using ebpf in Android networking||perhaps we'll get some collaboration with Linaro on testing and/or with beagle rack test boards||might have been the wrong crowd for the presentation (not networking & ebpf folks)|
Linaro Kernel Functional Testing (LKFT): functional testing of android common kernels
|There exists tool which can take kernel logs as input, and does some level of analysis looking for anomylies. Followup post LPC.||Confirmed KASAN and clang sanitizers are a logical next step. Prospects of including Android as part of the RC cycle on linux-stable were raised however no comment for/against was received.|
|Suren||Handling memory pressure on Android||No pushback against new syscall introduction.||- Need ION usage accounted in lmkd kill decisions|
- process_madvise() should be designed to support vectors for performance reasons. Maybe 2 versions? Error handling is still a question.
|Sumit||DMABUF Developments||Overall a good session, with clear recognition of issues we raised, specifically around partial cache flushing, and need to sort the CMOs for ARM devices. |
No apparent opposition from those present for the dma-buf heaps design philosophy.
|- Need to agree on clearing out dma-buf API usage around enforcing exclusive ownership boundaries between cpu and device.|
- Heap discovery needs to be discussed in context of AOSP
- Need to discuss Android need for Kernel Graphics Buffers (dma-buf+meta data), and investigate if that can be handled using drm fourcc and format modifiers.
|Alistair||DRM/KMS for Android, adoption and upstreaming||Proposals from drm/drm-misc maintainers to backport upstream (e.g. 5.4) version of drm core to older kernels for Android, to help decrease fragmentation of upstream and non-upstream GPU/display drivers.||DRM drivers can override fundamental features affecting userspace like drmIoctl. The Android/GKI kernels might need to take firmer steps than upstream to ensure baseline functionality/extensions are present|
|Suren||scheduler: uclamp usage on Android|
|Vincenzo||Memory tagging||The proposed Kernel Interface for userspace support of the Memory Tagging Extension seems understood and reasonably accepted.||- Deploy the inial patchset. Expected comments.|
"Wins" is any progress or agreement that has been made about the topic during the MC
"Work" is any work that was identified as being required to be done as a result of MC discussion
"Loses" is for highlighting issues which are clearly at an impass and are not forseen to be resolvable in their current form/approach
It's suggested to put major takeaways in bold. If, for example, within the 3 categories a given item is important enough that it should stand out in its meaningfulness (especially to outside observers) then making it bold (or underline) will help making it obvious "at a glance". For instance, if "Work" describes "Mergeable under condition that feature foo is made to use existing kernel API" and that's deemed an important advancement then that might be a good reason to put it in bold. Possibly end of week readouts should just call out the items in bold.