home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / research / 1073 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  4.4 KB
  1. Path: sparky!uunet!stanford.edu!agate!darkstar.UCSC.EDU!osr
  2. From: danh@quantum.qnx.com (Dan Hildebrand)
  3. Newsgroups: comp.os.research
  4. Subject: Re: Microkernel for Real-Time Computing
  5. Date: 18 Nov 1992 19:09:04 GMT
  6. Organization: Quantum Software Systems
  7. Lines: 71
  8. Approved: comp-os-research@ftp.cse.ucsc.edu
  9. Message-ID: <1ee4cgINNpsr@darkstar.UCSC.EDU>
  10. References: <1e92s7INN8dg@darkstar.UCSC.EDU>
  11. NNTP-Posting-Host: ftp.cse.ucsc.edu
  12. Originator: osr@ftp
  13.  
  14. In article <1e92s7INN8dg@darkstar.UCSC.EDU> yk7m@uvacs.cs.Virginia.EDU (Young-Kuk Kim) writes:
  15.  
  16. > Does anybody explain to me why and how a microkernel (e.g., Mach, Chorus)
  17. > can provide a deterministic computing base for real-time applications, 
  18. > while a traditional monolithic kernel cannot?
  19.  
  20. There is nothing that inherently prevents a monolithic kernel from 
  21. providing deterministic realtime scheduling. The microkernel / monolithic 
  22. comparison is very like the RISC / CISC comparison. For RISC, the idea is 
  23. that only the most "important" features should be implemented in silicon, 
  24. and the remainder in some other manner. By making the processor core 
  25. "simpler", additional effort ( and complexity ) can be expended to make 
  26. that "simple" core go fast enough to overcome the overhead of having to 
  27. implement the left out features in some other manner. Applying this 
  28. thinking to a microkernel OS, the idea is to implement only the 
  29. functionality that is most crucial to the performance, flexibility, 
  30. parallelism ( insert desired attribute here ) of the OS and implement the 
  31. remaining functionality as processes managed by that microkernel. The 
  32. team-of-processes model allows the microkernel to be much simpler ( and 
  33. potentially faster ) than a monolithic kernel. The trick is to use this 
  34. kernel to implement the remainder of the system such that it provides some 
  35. selected set of attributes better than the monolithic kernel equivalent. 
  36. Realtime determinism could be one such attribute.
  37.  
  38. > In other words, my questions are:
  39.  
  40. > 1. What are the advantages of microkernel for real-time applications
  41. > over a traditional monolithic kernel, and why?
  42.  
  43. A true microkernel ( not a 200 Kbyte "micro"-kernel ) can be roughly 
  44. compared to a realtime executive in terms of complexity and performance. 
  45. They both tend to deal with only the most fundamental operators necessary 
  46. to get an OS "off the ground", and by limiting the scope of the problem 
  47. tackled, provide very good performance. In our implementation of QNX, we 
  48. provided only first-level interrupt handling, message passing, process 
  49. scheduling and a connection point for an optional network task in less than 
  50. 7 Kbytes ( fits into the 486 8K onchip cache nicely :-). Everything else is 
  51. handled by optional, add on processes that provide higher levels of 
  52. functionality ( POSIX, etc ). The trick is to provide a level of context 
  53. switching and message passing performance that allows the optional, add-on 
  54. processes to provide their services as competently as the monolithic 
  55. equivalent. In order to do this sufficient functionality must be provided 
  56. so that the higher level services can be efficiently implemented, but not 
  57. so much that the generality of those services impacts the microkernel 
  58. performance.
  59.  
  60. > 2. What are the advantages of microkernel approach, comparing to 
  61. > traditional real-time executives? 
  62.  
  63. Typically, a microkernel will have been designed with the idea of adding 
  64. higher level OS services, while realtime executives tend to be an end in 
  65. themselves. The advantage, then, of the microkernel is that it can be 
  66. scaled up into larger, higher functionality operating systems without 
  67. having to replace everything from the kernel on up. This means that 
  68. services like file systems, networking, device managers, GUIs, device 
  69. drivers, etc. are all entities that run as processes much like any user 
  70. process. Done correctly, a minimal, realtime microkernel can be suitable 
  71. for tiny embedded applications, or incrementally scaled up into as complete 
  72. a realtime UNIX system as you could want. By being able to network-merge 
  73. the microkernels, hundreds of microkernels running on hundreds of 
  74. processors can be merged into a single logical machines.
  75.  
  76. I have a paper with more details if you're interested.
  77. -- 
  78. Dan Hildebrand                     email: danh@qnx.com
  79. Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
  80. (613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
  81. (613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8
  82.  
  83.  
  84.  
  85.