Archived/XPDS13 BoF Notes : Seeding an Android and Embedded ecosystem

Platforms

1. The overall agreement in the BoF was that Android on Xen should be platform agnostic
2. aka support ARM as well as Intel (e.g. many Android tablets in China are Intel based)

Missing Pieces for a complete Android system on top of Xen

1. Backend ION memory allocator (manages allocation of additional buffers). My understanding that what was needed is an ION memory allocator for PV drivers
   1. Samsung noted that a ION PV allocator may be need to be specialized for a particular SOC
   2. There was a bit of debate on whether it would be valuable to have a reference ION PV allocator
2. Wrapper user space Device Drivers for Graphic, Sound, USB, Giros, GPS, etc.
   1. These are not Linux drivers but user space drivers
   2. In most cases these will be shims, but some may be device specific
   3. A common place in the Xen Project (or even better in Android) where these could be put would help everyone
   4. The Xen Project could host a repo initially; as more momentum builds the case to approach Google is likely to increase

Pieces missing for Embedded (non-Android)

1. Xen Dom0 support in OpenWrt; DomU support exists
2. Soft-Real-time support - note that this was in the original Xen ARM port - see Xen_ARM_(PV). But it didn't make it across to the Xen on ARM support. Also see a related more general thread at xen-devel.
3. Hard-Real-time support: a US government standard / RT kernel / OS was mentioned. In my notes it says Arine7 ... but this is obviously wrong as google does not find anything.
4. Longer term: GPU virtualization - Video Card fragmenbtation is a huge issue
   1. Establish a list of GPUs vendors (note that this would be a very long list)
   2. Wait for Intel and Samsung to start submitting patches for their technology (see [1] and [2])
   3. Are there any software alternatives?
   4. Stefano (I think) made the point that the Android GPU interface would lend itself for a neat standard interface for GPU virt in Xen

Mechanics of Bootstrapping a Community

1. Lists
   1. The general consensus was that it would be a bad idea to create a new list. Discussions should happen on xen-devel
   2. However some attendees were concerned about the volume of traffic
   3. Threads related to ANDROID on xen-devel should be tagged with ANDROID
2. Meetings / Calls
   1. A monthly or less frequent open call would help
   2. Action Lars: write up minutes ✓, send out to all attendees and get the ones who'd be interested to reply whether'd be interested

Aside: I am wondering, whether a more low-volume list for bigger and longer-term developer discussions may be helpful. We have done this in the past and all the lists in question (IA64, ARM, ...), but over time these lists had to be culled when the developed features became mainstream. There have also been some discussion recently about the amount of traffic on xen-devel becoming a little painful. I am just putting this one up for debate, but this would probably grant a separate discussion.

Missing non-code pieces to speed up adoption

1. Sharing of information andf helping each other
   1. This comes back down to the list / meeting /calls part
2. Lack of documentation
   1. Step 1: create an embedded and android category on the wiki (and post these notes). Created http://wiki.xenproject.org/wiki/Category:Embedded and http://wiki.xenproject.org/wiki/Category:Android ✓
   2. Somebody to Volunteer to create a Getting Started with Xen on Android on the wiki
   3. A Hackathon hosted by a vendor that cares about Android / Embedded in 2014
   4. Have a central place / repo for Android user space drivers
      1. Open Question (for Android experts): is there something like an upstream for Android user space drivers today?
      2. How does one contribute (assuming such a place exists)?