Tim Robinson wrote:
Exokernels stike me as being similar to the DOS way of doing things: all programs have access to the hardware, and you've got to access it through libraries linked in with the application. Please correct me if I'm wrong.
There's some truth to that comparison, but it really misses some important qualities in exokernels. DOS was simple because all it was, essentially, was a filesystem and a simple command line user interface; exokernels are simple because the forego even those, but are still more complex than DOS in most other ways.
A better comparison is would be to imagine a standalone edition of VMware: it performs no services and provides no abstractions itself, but it allows several independent, specialized 'operating systems' to share the CPU, memory, and peripherals without needing to know of each others existence, and allows them to communicate between each other as if they were all on separate machines (though this need not be a feature of the exokernel itself, and strcitly speaking shouldn't be).
Unfortuantely, it is that last part - interprocess communication - that is the weakness of the exokernel philosophy. The exokernel design makes two important assumptuions
1) That most applications and services would be better served by drivers, etc. that are tuned to the specific task, rather than generic ones; and
2) That different applications rarely need to communicate betwen each other or share data or software, and that when they do a shared library is sufficent to provide the needed support.
These assumptions may hold true in the case of dedicated servers, though the rising use of HTTP servers like Apache and IIS as general-purpose meta-servers for accessing different services in a unified manner brings this into question. There is no question, however, that this does not hold in the case of a user workstation, especially GUI based ones. Even under a traditional shell, it is common for a user to have to access two or more different programs together, often in a way that could not have been predicted by the original programmer. In a GUI environment, it is rare for a user
not to not need to share data between disparate applications; entire systems (OLE, OpenDoc, .NET) have evolved to handle the need to access the multiple documents in varied formats in a single application, or allow different applications to use a single document. The use of multiple types of information - ASCII text, HTML and XML markup, image and sound files, client scripts and plug-ins in a variety of forms - is at the heart of the modern WWW browser, which has come to dominate among networking tools. In such a case, the overhead for IPC and sharing far outweighs the benefits of optimized code for special-purpose applications.
Login
Register
FAQ
Search
