Android MC @ 2019 Report
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
2
Android MC 2019 Progress Report
3
4
LeadTopicWinsWorkLoses
5
6
SandeepGeneric Kernel Image (GKI) progress
7
MatthiasMonitoring and Stabilizing the In-Kernel ABIGeneral 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).
8
SaravanaSolving issues associated with modules and supplier-consumer dependenciesOverall, 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.
9
AlistairAndroid Virtualization (esp. Camera, DRM)Interest in working on upstream virtio driver for gpio. Support of virtio strategy for Android emulation
10
Laurentlibcamera: Unifying camera support on all Linux systemslibcamera 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.
11
DanielEmulated storage features (eg sdcardfs)
12
AshishEliminating WrapFS hackery in Android with ExtFUSE (eBPF/FUSE)
13
MazeHow we're using ebpf in Android networkingperhaps we'll get some collaboration with Linaro on testing and/or with beagle rack test boardsmight have been the wrong crowd for the presentation (not networking & ebpf folks)
14
Tom
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.
15
SurenHandling memory pressure on AndroidNo 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.
16
SumitDMABUF DevelopmentsOverall 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.
17
AlistairDRM/KMS for Android, adoption and upstreamingProposals 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
18
Surenscheduler: uclamp usage on Android
19
VincenzoMemory taggingThe proposed Kernel Interface for userspace support of the Memory Tagging Extension seems understood and reasonably accepted.- Deploy the inial patchset. Expected comments.
20
21
Notes:
22
"Wins" is any progress or agreement that has been made about the topic during the MC
23
"Work" is any work that was identified as being required to be done as a result of MC discussion
24
"Loses" is for highlighting issues which are clearly at an impass and are not forseen to be resolvable in their current form/approach
25
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.
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...