[FoRK] Solving mobile OS upgrade / replacement / evolution: Android and beyond

Stephen Williams sdw at lig.net
Wed Dec 5 11:15:43 PST 2012

Right now, specific versions of an operating system with specific device drivers are needed for most hardware.  While Linux 
solves this by including device drivers for nearly every bit of hardware ever produced in a handful of MB, and Windows forces 
manufactures to provide matching drivers, the mobile OS world has to produce very specific builds for each device.

When the hardware is highly controlled, as with Apple, upgrades are relatively easy.  When there is an explosion of rapidly 
evolving hardware produced by different chipset vendors and OEMs, as there is with Android, the general result is that the OS 
only gets updated when the corresponding device is being actively marketed and supported.

There is an active community producing custom versions of Android, and even completely different operating systems based on 
Linux+Qt etc.  However, they have to go through gyrations to have even basic device drivers working, let alone getting all 
peripherals to work.

On the hardware side, some chipsets do everything with a few big processors (CPU, GPU, DSP) and a small handful of asics while 
other chipsets have many custom processing hardware blocks, often managed by extra CPUs.  Often, there are several realtime OSes 
running on the subsystem processors that are handled by Android/Linux device drivers.

The next step in the evolution of this situation should be to separate all device driver implementation and runtime into a 
separate subsystem that could remain stable on a system and be upgraded independently from the main operating system.  This was 
done somewhat with EFI BIOS, although the goals there produced something that works for different processor types but isn't 
really appropriate for continue OS use.  What we need is an architecture that is at least as efficient as the main processor 
running custom device drivers, but one that allows the operating system to be completely open source, hardware independent, and 
that can be replaced at any point in the future and still work as well as when the device shipped.

This could be done with a single processor running a hypervisor or with at least one driver-space CPU running an independent 
kernel. For mobile devices, the latter is more or less available now and easily designed in.  Communication should primarily be 
through a shared memory bus, spin locks, and a very small number of interrupt / wakeup mechanisms.  All Android/Linux device 
drivers would have a standard, extensible driver interface for the type of driver (gyro, GPU, sound, etc.).  The ideal 
communication mechanism uses prioritized event queues, a shared memory pool, cache coherency management (supporting both cc-numa 
and non-cc-numa hardware), and physical / virtual and L2/L3 cache management.

On the hypervisor side, a clearly defined interface would be needed to allow the main OS kernel to coexist with the device 
driver real-time kernel.  This could be done with a single processor and have the same effect.  It is possible to do this with 
the same apparently interface, although it might be more efficient to have two modes.

There would likely need to be a few special types of meta-driver with tight API to detailed driver type coupling, mainly around 
GPU and perhaps DSP, but these can be minimized and standardized so that it is not difficult to support all of these in future 
operating systems.  At some level of hardware (when the driver processor can run clang/llvm to compile shaders / OpenCL and 
evolution of that kind of thing matures), they can probably be eliminated.  OpenMax is the new standard API for supporting 
various subprocessors.  The key mechanism is shared memory buffer passing that supports zero copy with proper cache flushing, 
locking, and synchronization.

The result of this is that every device with enough memory, storage, and minimum set of peripherals (touch screen etc.) could 
run every future operating system.  The main hurdle would be to assuage the desire of chipset, OS, OEM, and carrier parties to 
lock devices into certain ranges of use for a certain period of time.  We could get past this or it could be accommodated 
relatively easily since the device subsystem processor pretty much has control of the system.

Note that this is exactly the kind of interface needed for virtualization and supercomputer hardware hosting.  A system like the 
Cray XT[345] has many compute nodes with just RAM and a connection mesh and a few "service nodes" that have local device drivers 
and PCI-E slots.  Device drivers running on those nodes could be communicated with over other nodes in a transparent way.

There.  Public disclosure.  Interested parties, you have one year to work with me to patent this in the US.  ;-)


Stephen D. Williams sdw at lig.net stephendwilliams at gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer

More information about the FoRK mailing list