KS2011: Patch review

Posted Oct 25, 2011 3:55 UTC (Tue) by dlang (guest, #313)
Parent article: KS2011: Patch review

I would love to have the a ability to put a kernel.org kernel on my devices that shipped with android. I see far too much work going on with people writing drivers for (in kernel.org terms) ancient kernels.

in many cases there is a driver for a device in a new kernel, but since that's not an 'android' kernel, people spend a lot of time duplicating or backporting drivers.

I'm not saying that the kernel.org kernel needs to accept all the implementation details of the android kernels, but they do need to accept enough that the interfaces can be made available and the result at least run.

in the case of wakelocks, on my tablet I don't have all the different weird things going on that can happen on a phone, so I would even be happy with a noop version of wakelocks that didn't actually do anything beyond allowing the android userspace to run without complaining.

KS2011: Patch review

Posted Oct 25, 2011 7:33 UTC (Tue) by swetland (guest, #63414) [Link] (7 responses)

I'd love that too!

To be very clear, we (Google/Android) are not opposed to some level of compromise, incremental shifts, and migration of APIs. We just find the "no you should throw it all away and rewrite your userspace to be different" approach to be something we're not interested in doing.

I suspect there's a middle ground somewhere between "put all of the Android changes in the kernel unmodified right now" and "delete them forever because they suck". Here's hoping we find it.

KS2011: Patch review

Posted Oct 25, 2011 8:00 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

not counting hardware drivers for the moment, is there a list of what interfaces would need to get added to the kernel.org kernel to get Android userspace to run on it?

and then of those interfaces, which ones need to actually be something other than a stub?

for example, wakelocks could probably be a stub, but an inter-process communications would have to actually work (I seem to remember reading that Android had a kernel assisted IPC protocol)

KS2011: Patch review

Posted Oct 25, 2011 8:08 UTC (Tue) by swetland (guest, #63414) [Link] (5 responses)

I'd need to look through things, but I suspect the answer is "not many", though some of them are pretty important (at least to Android).

Some of the notable ones off the top of my head:
- wakelocks
- binder (IPC subsystem) -- /dev/binder -- self-contained, in theory one could replace it with an entirely userspace implementation, in practice probably a lot of work
- logger driver -- /dev/logs/* -- multiple ring buffers for logging state without a lot of context switch overhead -- back when running on virtually tagged ARM9s this was very useful
- ION -- /dev/ion -- a unified approach to buffer management and sharing between display, GPU, camera, codecs, etc, new in Ice Cream Sandwich

Where possible we try to use standard interfaces -- for example, the power supply framework for battery charging and status, a lot of assorted interfaces via /sys, etc.

KS2011: Patch review

Posted Oct 25, 2011 8:17 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

is the logger driver really needed for the userspace to run? could you point me to documentation on it?

as for ION, since there is no code available yet, it's hard to talk about it.

KS2011: Patch review

Posted Oct 25, 2011 8:23 UTC (Tue) by swetland (guest, #63414) [Link] (1 responses)

Userspace should fail over to dropping all logs on the floor. Not useful but it should work.

We're still getting back online after the kernel.org downtime, so I don't have a handy URL for browseable source. Before kernel.org went down the ION kernel side sources were being developed in the open in the kernel repositories at android.git.kernel.org.

Hopefully it'll all be sorted out in the near future alongside the ICS userspace source release.

KS2011: Patch review

Posted Oct 25, 2011 18:01 UTC (Tue) by dlang (guest, #313) [Link]

this is the sort of thing I was thinking about when I was saying that things just needed to run, not implement everything.

I am thinking that the interfaces needed to just make things 'run' on a kernel.org kernel is much smaller than what people have been trying to get submitted. And then once this smaller set is in place, things can be worked on much more easily.

while I have your attention, did you see Neil Brown's proposal for a userspace wakelock-type daemon? how hard would it be to modify the Android userspace to work with his proposal? As I understand it, there's only one daemon that actually talks to the kernel, everything else in the Android userspace talks to that daemon.

KS2011: Patch review

Posted Oct 25, 2011 9:31 UTC (Tue) by xav (guest, #18536) [Link] (1 responses)

Interesting. How does ION relate to the DMA buffer sharing mechanism [1] currently in discussion ?

[1] https://lwn.net/Articles/462524/

KS2011: Patch review

Posted Oct 26, 2011 15:37 UTC (Wed) by a0273185@ti.com (guest, #74477) [Link]

ION provides memory allocation and buffer sharing using file descriptors. The allocations come from carveouts.

dmabuf just deals with buffer sharing.

I imagine CMA + dmabuf would displace ION.