Stanford University researchers are designing an operating system from the ground up to handle the power and security requirements of mobile devices.
The Cinder operating system is already working on an Arm chip, and members of the team are working on making it run on the HTC G1 handset, according to Philip Levis, a Stanford assistant professor. Levis spoke about Cinder at the Stanford Computer Forum on Tuesday.
If an application isn't running as fast as the user wants, a Cinder-based phone could include a button to boost the energy allocated to that application, Levis said. Cinder also could allow users to download any code and run it safely on their phones in a "sandbox" mode.
Levis, another Stanford professor and a team of students are designing Cinder from scratch because the time has come for a mobile operating system that isn't derived from other platforms, he told the gathering of students and industry professionals.
Using Linux as an example, he said operating systems designed for larger hardware platforms aren't ideal for mobile devices because many requirements are significantly different.
Cinder taps into some innovations in HiStar, another OS developed at Stanford, but the team is not building in backward compatibility with established platforms, Levis said. They want to avoid handing down core characteristics that aren't appropriate to mobile, and they can always write adaptation layers on top for backward compatibility, he said.
Security and power management are the main problems the team is trying to solve. In the security arena, they want to make both trusted and untrusted applications safe to use. Borrowing from HiStar, Cinder will do this by tracking how data flows through a system instead of tracking code, Levis said.
The main focus of Levis' talk was power management, the component of the OS he is overseeing. Cinder can prevent unintended battery drains, make sure an application can run for as long as users want, and even let users boost power levels, he said. It could also provide more detailed battery-life information on a handset's home screen.
Cinder will be able to know in detail how much energy each part of an application uses, and to budget power for that component. This should help to solve the problem of an unknown computing process continuously running in the background and draining a phone's battery.
Rather than forcing the owner of the phone to notice the battery is being drained too quickly, find the application that's draining it and stop that process, Cinder would be able to control how much power the process uses, Levis said.
The OS could also dole out power based on how long a user typically wants to use an application. For example, if someone wanted to watch a movie on the device for two hours, Cinder could force the video player software to use power at a certain rate so it could survive for that period of time.
Applications built into a phone might have default settings controlling their power consumption based on how people are likely to use them, but it would be hard to set those parameters for newly downloaded software, Levis said.
Those applications could be assigned to run in a highly constrained mode at first, which would ensure that unfamiliar software couldn't quickly drain the battery. Then, if users found the new application ran too slowly, they could push a "more power" button to boost the power allocated to it, he said.
Cinder uses a variety of mechanisms to achieve this level of power control. The main piece is what Levis called the "power lock," a simple mechanism to control all kinds of workloads. It takes the place of what may be dozens of different policies in a typical system today, he said.
The OS also uses asynchronous I/O, a feature used in high-performance servers today. Asynchronous I/O cuts down on delays from communication between applications and the operating system and lets the OS schedule workloads. Whereas asynchronous I/O is used in servers for performance reasons, Cinder would use it to minimize power consumption, Levis said.