home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / linux / 25139 < prev    next >
Encoding:
Text File  |  1993-01-23  |  3.1 KB  |  65 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!news.funet.fi!funic!nntp.hut.fi!nntp!jem
  3. From: jem@snakemail.hut.fi (Johan Myreen)
  4. Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
  5. In-Reply-To: sct@dcs.ed.ac.uk's message of 21 Jan 93 16:26:33 GMT
  6. Message-ID: <JEM.93Jan22202315@lk-hp-6.hut.fi>
  7. Sender: usenet@nntp.hut.fi (Usenet pseudouser id)
  8. Nntp-Posting-Host: lk-hp-6.hut.fi
  9. Organization: Helsinki University of Technology, Finland
  10. References: <1993Jan14.154308.2640@oucsace.cs.ohiou.edu>
  11.     <1993Jan14.172817.7750@aston.ac.uk> <jeremy.727514644@chao>
  12.     <SCT.93Jan21162633@carna.dcs.ed.ac.uk>
  13. Date: 22 Jan 93 18:23:15 GMT
  14. Lines: 49
  15.  
  16. In article <SCT.93Jan21162633@carna.dcs.ed.ac.uk> sct@dcs.ed.ac.uk (Stephen Tweedie) writes:
  17. >In article <jeremy.727514644@chao>, jeremy@sw.oz.au (Jeremy Fitzhardinge) writes:
  18. >> I have no objection to things being added to Linux if they are useful,
  19. >> but System V-type IPC are not the way to go - they are BAD.  The main
  20. ...
  21. >> I would suggest that mmap() type shared memory should be implemented.
  22.  
  23. >I agree with you from the "operating systems philosophy" point of
  24. >view.  Unfortunately, compatibility and performance are also issues.
  25. >We currently DO have SYSV-IPC as a kernel option; there is too much
  26. >software out there using these facilities to give them up.
  27.  
  28. I'm curious: how much software is there really that uses SYSV IPC,
  29. without any alternate way to go? As we are talking about Linux here,
  30. only free software counts. Could you give some examples of software
  31. like this? (This should not be taken as a flame, I really want to
  32. know.)
  33.  
  34. Somebody else said that keeping the linux kernel small can be done
  35. with conditional compilation and let the user decide what goes in and
  36. what doesn't. That's not what I meant by keeping the kernel small, to
  37. try to keep the kernel image file as small as possible. Perhaps
  38. 'non-hairy' is a better word. A known Linux hacker once said: "If I
  39. were to choose between a feature filled kludged kernel and a piece of
  40. art, I'd take the piece of art." Compile time configuration could make
  41. things even worse, filling the code with #ifdef this and #ifndef
  42. that... (I'm not particularly a friend of the C preprocessor.
  43. Somtimes I feel like writing an article called "The C Preprocessor
  44. Considered Harmful".)
  45.  
  46. In another article somebody asked something like "if we want to keep
  47. the kernel simple, why do we have soundcard support etc..." I haven't
  48. looked at the soundcard code, but I think there's a difference between,
  49. for instance, adding drivers for various pieces of hardware and adding
  50. features which have a significant impact on the whole kernel, cutting
  51. deep into the foundations of the design. This is especially true when
  52. the features to be added start to overlap with other features of the
  53. kernel.
  54.  
  55. Note that what I've said above does not neccessarily apply to the SYSV
  56. IPC patches, they just happened to provoke me to post the article that
  57. started this thread. But I still think bloating the kernel with
  58. feature after feature isn't a good idea.
  59.  
  60. As usual, these are just my thoughts on the issue.
  61.  
  62. --
  63. Johan Myreen
  64. jem@cs.hut.fi
  65.