|
|
|
|
|
|
by ajross
5197 days ago
|
|
|
Sounds like an interesting thesis. You have a link to one of these design or implementation "issues" and how it's a reflection of the lack of address space separation and/or IPC design of the linux kernel? No? Yeah; sounded like a content-free platform flame to me too. Actually: I'd be curious to hear some more knowledgable folks on this. My understanding of the iOS kernel is that it's a microkernel only via historical label: the PVR driver stack, network devices and filesystems live in the same address space and communicate with userspace via single context switched syscalls. Is that wrong? |
|
|
The Android kernel code is more than just the few weird drivers that were in the drivers/staging/android subdirectory in the kernel. In order to get a working Android system, you need the new lock type they have created, as well as hooks in the core system for their security model.
In order to write a driver for hardware to work on Android, you need to properly integrate into this new lock, as well as sometimes the bizarre security model. Oh, and then there's the totally-different framebuffer driver infrastructure as well.
This means that any drivers written for Android hardware platforms, can not get merged into the main kernel tree because they have dependencies on code that only lives in Google's kernel tree, causing it to fail to build in the kernel.org tree.
Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on.
Now branches in the Linux kernel source tree are fine and they happen with every distro release. But this is much worse. Because Google doesn't have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community. The kernel community has for years been telling these companies to get their code merged, so that they can take advantage of the security fixes, and handle the rapid API churn automatically. And these companies have listened, as is shown by the larger number of companies contributing to the kernel every release.
But now they are stuck. Companies with Android-specific platform and drivers can not contribute upstream, which causes these companies a much larger maintenance and development cycle.
http://www.kroah.com/log/linux/android-kernel-problems.html
For your 2nd question
In Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks. This modular structure results in a more robust and extensible system than a monolithic kernel would allow, without the performance penalty of a pure microkernel.
http://developer.apple.com/library/mac/#documentation/Darwin...