home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9475 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  3.0 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!Sirius.dfn.de!ira.uka.de!uni-heidelberg!rz.uni-karlsruhe.de!usenet
  2. From: S_TITZ@iravcl.ira.uka.de (Olaf Titz)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: RISC approach to OS - Re: GNU kids on the block?
  5. Message-ID: <1992Aug31.111758.25243@rz.uni-karlsruhe.de>
  6. Date: 31 Aug 92 11:17:58 GMT
  7. References: <1992Aug25.195316.9174@kithrup.COM> <1992Aug27.135703.9312@crd.ge.com> <1992Aug28.171744.6460@rz.uni-karlsruhe.de> <1992Aug28.174743.8140@colorado.edu>
  8. Sender: usenet@rz.uni-karlsruhe.de (USENET News System)
  9. Organization: Fachschaft Informatik, Uni Karlsruhe
  10. Lines: 53
  11. In-Reply-To: drew@ophelia.cs.colorado.edu's message of 28 Aug 92 17: 47:43 GMT
  12. X-News-Reader: VMS NEWS 1.23
  13.  
  14. In <1992Aug28.174743.8140@colorado.edu> drew@ophelia.cs.colorado.edu writes:
  15.  
  16. >  In article <1992Aug28.171744.6460@rz.uni-karlsruhe.de> S_TITZ@iravcl.ira.uka.de (Olaf Titz) writes:
  17. >  >
  18. >  >While the Linux kernel does its job well, its being monolithic is a
  19. >  >problem since all of the parts are interdependent, and to comprehend
  20. >  >the work of one of them, you have to know the whole system. This may
  21. >  >work for Linux but is unacceptable for bigger systems.
  22. >  
  23. >  This isn't true - although the kernel is one big chunk of 
  24. >  code, it is subdivided into smaller modules, such as the VM 
  25. >  code, each one of the file systems, each device driver, etc.  Some of these
  26. >  modules have incestous relationships with eachother due to various
  27. >  kludges and hacks, but this isn't necessary.
  28.  
  29. OK, its modularized, but the problem ARE the kludges and hacks. I have
  30. done some patching of the screen blanking code - I thought it was in
  31. console.c but was astonished how many modules actually were involved.
  32. (Btw. console.c is too big and does too many things, IMHO. But there's
  33. nothing to say fundamentally against it, as all is working well :-)
  34.  
  35. >  You do have to understand some basic "common" things used in the 
  36. >  kernel - ie, how the fs register points into user space, how 
  37. >  sleep/wakeup work, etc, but to say you have to understand the 
  38. >  whole kernel to write a device driver is a gross overstatement.
  39.  
  40. OK, it's an overstatement. And the scheduler is indeed one of the
  41. finest I know - sleep/wakeup can really be /that/ easy...
  42.  
  43. >...
  44. >  I agree too - 1.5 - 3M for a typical vendor's kernel is outrageous, 
  45. >  when it doesn't do anything that a generic 500K BSD or Linux kernel
  46. >  can't do.
  47.  
  48. By developing ever bigger RAM chips hardware manufacturers unwillingly
  49. (???) spawn new proofs for Parkinsons Law of Data every 2 years :-(
  50.  
  51. >...
  52. >  Blasphemy! There is nothing but the one true EMACS! :-)
  53.  
  54. Tell me which version :-)
  55.  
  56. >  Boycott AT&T for their absurd anti-BSDI lawsuit.
  57.  
  58. System V Rel. 4 is a sufficient reason too. Cf. memory consumption.
  59.  
  60. MfG,
  61.         Olaf
  62. -- 
  63. Olaf Titz - comp.sc.student - Univ of Karlsruhe - s_titz@iravcl.ira.uka.de -
  64. uknf@dkauni2.bitnet - praetorius@irc - +49-721-60439 - did i forget something?
  65. The only use I can find for vi is editing the emacs sources
  66.  while porting them to a new machine. - Larry Campbell
  67.