The following was our response in perhaps 2002 to a note from a builder of cell phones.
The note from xxx suggests that the Keykos kernel is not currently adapted to cell phone systems. This is certainly true. It is clear that work is necessary here to accomplish that requirement. We have anticipated using expertise and perhaps extant code to adapt our system to cell phone requirements.

We are well aware that software in the phone environment must be extremely sensitive to the energy budget. To provide energy efficient software requires efficiency at all levels. To be efficient a computation must be accomplished with few instructions which is the same requirement as for fast software. Keykos achieved outstanding performance in the few benchmarks that we implemented. It is thus a prime candidate for energy efficient applications. Other less obvious requirements are to idle without issuing instructions. Keykos has always done this on machines with a hardware mode (a wait state) that would cease to issue instructions but remain available to interrupts.

Regarding access to novel hardware features specific to the purpose of the system, Keykos has adapted to four diverse system architectures now, some with rather novel system interfaces such as to a display screen. In these cases we have always found efficient and secure ways to provide application code access to these system features.

We anticipate that cell phones have now and will have in the future novel interfaces between the audio world and the RF world.

The Keykos kernel is the smallest of any kernel of which I am aware that aspires to provide a general software platform which provides any degree of control over what actions application software can take. There are probably smaller kernels that are now deployed in cell phones now but I would suspect that smaller current systems cannot maintain order between a growing set of imperfect applications.

The main contribution of a Keykos like system is an architecture predicated on capability discipline that avoids the deep security hole that Microsoft currently finds itself in. Other prominent systems are as week but MS is especially vulnerable because of its architecture where applications have excessive authority. It is not enough to provide separate address spaces to different applications; one must also provide distinct and appropriate spaces of actions as well. Keykos and attendant disciplines do this naturally and efficiently.

There is concern over time taken to track new hardware platforms. Here are some points that bear on Keykos in such an environment.

No new hardware system arises in less than many months. If software groups have a budget and information about emerging platform details, and if the new hardware is able to provide requisite security, then there should be no problem in making a software release in a timely manner. Capability systems have been built for much more diverse hardware systems than I see today.

Capability discipline ensures that users of existing hardware features are known to the system architects for the kernel mediates between application software and hardware features via capabilities which are explicitly granted to those applications which can invoke them.

Furthermore Keykos is in a position to provide virtual facilities in the new system that play a functional role equivalent to those of an earlier system.