Slashdot Mirror
Symbian Microkernel Finally Goes Open Source
ruphus13 writes "Symbian announced over a year ago that they were going to Open Source their code, and the industry has been patiently waiting for that to happen. Well, it finally has. According to news on Wednesday, 'Symbian has released its platform microkernel and software development kit as open source under the Eclipse Public License. The Symbian Foundation claims that it is moving quickly toward an open source model, which is questionable, but the release of the EKA2 kernel is a signal that Symbian still means business about adopting an open source model. Accenture, ARM, Nokia and Texas Instruments contributed software to the microkernel, Symbian officials said.'"
``A microkernel architecture for devices least able to afford the overhead'' What overhead? The way I understand it, the overhead typically associated with microkernels comes two sources: overhead incurred when transferring control across process boundaries and inefficiency of the implementation. Inefficiency of the implementation (e.g. using a complex message-passing system that consumes many CPU cycles) is a problem, but it's not intrinsic to microkernels. Overhead incurred when transferring control across process boundaries depends on many factors, such as what your OS's idea of "process" is, how this is mapped to the constructs provided by the hardware, and how efficient the hardware implementation is. Long story short, implementing processes as tasks on x86 hardware and using the MMU to separate processes' address spaces is very inefficient. An implementation on an MMU-less system with an ARM CPU and all processes in the same address space would not be nearly as inefficient. In fact, on an ARM CPU, even with an MMU and processes in separate address spaces, one study (PDF) has measured the context switching overhead of Linux to be up to 0.25%. If Linux can do that, a microkernel can, too. Now, I don't know about you, but 0.25% isn't enough to keep me awake with worry all night. All in all, I think the reputation that microkernels have for introducing a lot of overhead is simply due to inefficient implementations on inefficient hardware. I also wonder how much kernel efficiency still matters these days; it seems that most programs seem to fall in one of 3 categories: 1) mostly sitting idle waiting for input (user input, disk reads, memory access) 2) bound mostly by the speed of the graphics card 3) spending most of their CPU cycles in their own code or libraries. System call overhead has little impact on these programs ...
Please correct me if I got my facts wrong.
This issue is clearly being pushed forward by open-source Android. Smarter - and, maybe, weaker- competitors realize they must match Android's flexibility and openness.
Windows Mobile will either have to offer an extremely compelling experience, Apple-like, or will be FOSSed into oblivion ? I'm taking bets, but only one way ^^
Dream scenario: Smartphones -> Tablets/ebooks -> Netbooks -> PCs.
Well, in the long run S60 it probably not the one to do that. But Maemo or Android, in a "bigger" version ?
The Cloud - because you don't care if your apps and data are up in the air.
In other words, standard FAT file path conventions. The most used file system in the world. As used by about 90% of people's desktop computers.
Doing what your customers ask and pay you for is never a bad decision for development. SymbianOS customers being handset manufacturers.
Symbian exceptions predated the introduction of exceptions to C++. So it wasn;t a choice not to go with the standard, rather that Symbian was a pioneer. Symbian does have several descriptor classes, and that is confusing. But they are there for reasons of memory efficiency on what were devices with tiny memories. Properly written Symbian code will do string storage and manipulation with less memory than any other API I know.
Again, pioneering stuff. The responsiveness of multi-threaded applications without the overhead of multi-threading.
Symbian was originally written for a device with 16Mhz ARM chip. If a microkernal was OK for that, it's OK for the far more beefy specs of today's smartphones. The problem isn't with the reality of Symbian OS, it's with your entirely imagined notion of what the requirements of a microkernel are. It's a microkernel chiefly because embedded devices such as phones have to run reliably for long period of time. That's more important than marginal speed differences.
Strange = different from what you're used to.
You complaints are a mixture of not knowing the perfectly sound reasons for engineering design decisions, and your arbitrary view that Unix is the one true way.