home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / research / 1142 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  1.6 KB
  1. Path: sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!osr
  2. From: peter@ferranti.com (peter da silva)
  3. Newsgroups: comp.os.research
  4. Subject: Re: On debugging (was Re: Microkernel for Real-Time Computing)
  5. Message-ID: <1glfuhINNcfm@darkstar.UCSC.EDU>
  6. Date: 15 Dec 92 20:41:53 GMT
  7. References: <1fgqaaINNntl@darkstar.UCSC.EDU> <1g35g7INNfvt@darkstar.UCSC.EDU> <1giuu1INNmp3@darkstar.UCSC.EDU>
  8. Organization: Xenix Support, FICC
  9. Lines: 23
  10. Approved: comp-os-research@ftp.cse.ucsc.edu
  11. NNTP-Posting-Host: ftp.cse.ucsc.edu
  12. Originator: osr@ftp
  13.  
  14. In article <1giuu1INNmp3@darkstar.UCSC.EDU> tage@cs.utwente.nl (Tage Stabell-kuloe) writes:
  15. >     Which (in this context) is a software-engineering solution to a 
  16. >     debugging problem.
  17.  
  18. So is pretty much ALL memory protection hardware, no? After all, Burroughs
  19. showed you didn't REALLY need all that stuff, right?
  20.  
  21. >     There is no such thing as a free lunch.  It is more expensive for one 
  22. >     service in the kernel to [insert your favourite IPC mechanism here] in 
  23. >     order to inform another part of some event, then just jumping to it. 
  24.  
  25. Sure, but if you simultaneously speed up IPC (like, by making the kernel
  26. small enough to fit in the on-chip cache) then everything in the system
  27. becomes faster. If you speed up IPC enough, it becomes lost in the noise.
  28. If one of the reasons for the kernel's speed is its size, you slow things
  29. down by moving them back in.
  30.  
  31. Personally, I think the ideal solution would be to provide a binary interface
  32. to the kernel that reains the same whether you're running in the kernel
  33. address space or not, so moving things into and out of the kernel simply
  34. becomes a matter of performance tuning.
  35. -- 
  36. Peter da Silva
  37.