From: danh@quantum.qnx.com (Dan Hildebrand)
Newsgroups: comp.os.research
Subject: Re: Microkernel for Real-Time Computing
Date: 18 Nov 1992 19:09:04 GMT
Organization: Quantum Software Systems
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp

In article <1e92s7INN8dg@darkstar.UCSC.EDU> yk7m@uvacs.cs.Virginia.EDU (Young-Kuk Kim) writes:

> Does anybody explain to me why and how a microkernel (e.g., Mach, Chorus)
> can provide a deterministic computing base for real-time applications, 
> while a traditional monolithic kernel cannot?

There is nothing that inherently prevents a monolithic kernel from 
providing deterministic realtime scheduling. The microkernel / monolithic 
comparison is very like the RISC / CISC comparison. For RISC, the idea is 
that only the most "important" features should be implemented in silicon, 
and the remainder in some other manner. By making the processor core 
"simpler", additional effort ( and complexity ) can be expended to make 
that "simple" core go fast enough to overcome the overhead of having to 
implement the left out features in some other manner. Applying this 
thinking to a microkernel OS, the idea is to implement only the 
functionality that is most crucial to the performance, flexibility, 
parallelism ( insert desired attribute here ) of the OS and implement the 
remaining functionality as processes managed by that microkernel. The 
team-of-processes model allows the microkernel to be much simpler ( and 
potentially faster ) than a monolithic kernel. The trick is to use this 
kernel to implement the remainder of the system such that it provides some 
selected set of attributes better than the monolithic kernel equivalent. 
Realtime determinism could be one such attribute.

> In other words, my questions are:

> 1. What are the advantages of microkernel for real-time applications
> over a traditional monolithic kernel, and why?

A true microkernel ( not a 200 Kbyte "micro"-kernel ) can be roughly 
compared to a realtime executive in terms of complexity and performance. 
They both tend to deal with only the most fundamental operators necessary 
to get an OS "off the ground", and by limiting the scope of the problem 
tackled, provide very good performance. In our implementation of QNX, we 
provided only first-level interrupt handling, message passing, process 
scheduling and a connection point for an optional network task in less than 
7 Kbytes ( fits into the 486 8K onchip cache nicely :-). Everything else is 
handled by optional, add on processes that provide higher levels of 
functionality ( POSIX, etc ). The trick is to provide a level of context 
switching and message passing performance that allows the optional, add-on 
processes to provide their services as competently as the monolithic 
equivalent. In order to do this sufficient functionality must be provided 
so that the higher level services can be efficiently implemented, but not 
so much that the generality of those services impacts the microkernel 
performance.

> 2. What are the advantages of microkernel approach, comparing to 
> traditional real-time executives? 

Typically, a microkernel will have been designed with the idea of adding 
higher level OS services, while realtime executives tend to be an end in 
themselves. The advantage, then, of the microkernel is that it can be 
scaled up into larger, higher functionality operating systems without 
having to replace everything from the kernel on up. This means that 
services like file systems, networking, device managers, GUIs, device 
drivers, etc. are all entities that run as processes much like any user 
process. Done correctly, a minimal, realtime microkernel can be suitable 
for tiny embedded applications, or incrementally scaled up into as complete 
a realtime UNIX system as you could want. By being able to network-merge 
the microkernels, hundreds of microkernels running on hundreds of 
processors can be merged into a single logical machines.

I have a paper with more details if you're interested.
-- 
Dan Hildebrand                     email: danh@qnx.com
Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8