Android MC @ 2018 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 2018 Progress Report
3
4
LeadTopicWinsWorkLoses
5
6
MartijnSymbol Namespacepositive response, no objectionsget the patches in :-) Figure out granularity of namespaces
7
SurenAndroid usage of memory pressure signals in userspace low memory killerpresented future plans, no major complainsneed to consider the feedback
8
ChristianDynamically Allocated Binder Devices
9
PatrickHow to be better citizens: from changes review to changes testingpresented a simple setup to evaluate power/perf effects of proposed patchesverify with Linaro if what they have is a suitable implementation of the proposed approachlimited interest in integrating such a solution in AOSP's gerrit
10
Daniel/PaulUserdata fs CheckpointingPresented checkpoint concept - people understood the need and were supportiveAttempt to reconcile our approach with more traditional checkpoint approaches
11
DavidLVM, device mapper and dm-linearSmall, contained device mapper library was added in Android for this and for the most part this went without any doubts / concerns.None needed. LVM may need re-consideration. However, its a big codebase to pull into Anroid compared to the small library that we have right now.Couple of assumptions made about LVM metadata turned out to be wrong.
12
SandeepReadiness of ARM64 Kernels for Running on Any DeviceARM64 kernels has always been ready - confirmedExpected work in IOMMU and potentially clock framework.
13
JoelHow to get ashmem out of stagingDeleting pin/unpin code from ashmem (Chrome study still in progress, but should be no problem doing that)Make a plan for handling of /dev/ashmem opencoded usages
14
SandeepThe Android DTS fstab node work TrebleEverybody agreed to the proposed solution and it doesn't need to be altered in AOSP.
15
AlistairDRM/KMS for Androideverybody agrees we should do itneed to get i-g-t tests into aosp, and get at least one aosp device passing them
16
LauraION upstreaming updategetting the location for cache ops is a very hard problemGoing to try again with a wrapper to call cache ops, hopefully more successfully. Reviewing uncached patches.
17
AlistairCuttlefishlots of interest in using cuttlefishshould add new virtio_gpu_3d enum for non-virgl control stream format. need to enable new gpu architecture. should have something better than emulated camera (virtio video?)
18
19
Notes:
20
"Wins" is any progress or agreement that has been made about the topic during the MC
21
"Work" is any work that was identified as being required to be done as a result of MC discussion
22
"Loses" is for highlighting issues which are clearly at an impass and are not forseen to be resolvable in their current form/approach
23
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.
24
25
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...
Main menu