home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / linux / 24991 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.4 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!warwick!uknet!edcastle!dcs.ed.ac.uk!sct
  2. From: sct@dcs.ed.ac.uk (Stephen Tweedie)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Creeping featursm (Was: Re: ANNOUNCE: linux-0.99 patchlevel 3)
  5. Message-ID: <SCT.93Jan21162633@carna.dcs.ed.ac.uk>
  6. Date: 21 Jan 93 16:26:33 GMT
  7. References: <1993Jan14.154308.2640@oucsace.cs.ohiou.edu>
  8.     <1993Jan14.172817.7750@aston.ac.uk> <jeremy.727514644@chao>
  9. Sender: cnews@dcs.ed.ac.uk (UseNet News Admin)
  10. Organization: University of Edinburgh Dept. of Computer Science, Scotland
  11. Lines: 37
  12. In-Reply-To: jeremy@sw.oz.au's message of 20 Jan 93 07:24:04 GMT
  13.  
  14. In article <jeremy.727514644@chao>, jeremy@sw.oz.au (Jeremy Fitzhardinge) writes:
  15. > I have no objection to things being added to Linux if they are useful,
  16. > but System V-type IPC are not the way to go - they are BAD.  The main
  17. > problem is that they use a completely different set of access methods
  18. > and name space to everything else in the unix kernel.  Because they
  19. > have very little common overlap with existing code, there is a higher
  20. > chance of bugs, and a disproportionate amount of extra code for the
  21. > extra functionality.
  22.  
  23. > I would suggest that mmap() type shared memory should be implemented.
  24. > This is where a file gets mapped into a process's address space.
  25. > All the processes mapping the same file get the same memory pages in
  26. > their address spaces.  The mappings can be set up so modifications to
  27. > the mapped pages can either be shared or private.
  28.  
  29. I agree with you from the "operating systems philosophy" point of
  30. view.  Unfortunately, compatibility and performance are also issues.
  31. We currently DO have SYSV-IPC as a kernel option; there is too much
  32. software out there using these facilities to give them up.
  33.  
  34. IF we can implement SYSV-IPC in an efficient and totally
  35. user-transparent way by building library calls on top of shared
  36. memory, then that will be a reasonable way to go.  If not, then I
  37. don't think we should strip the existing code from the kernel; it is
  38. too useful, even if ugly.  We can always make it a kernel
  39. configuration option.
  40.  
  41. However, that does not mean that mmap() for normal files is not worth
  42. while.  It would be a clean and useful extension to the kernel.  I
  43. just don't think we should throw away compatibility for the sake of
  44. aesthetics.
  45.  
  46. Cheers,
  47.  Stephen Tweedie.
  48. ---
  49. Stephen Tweedie <sct@uk.ac.ed.dcs>   (Internet: <sct@dcs.ed.ac.uk>)
  50. Department of Computer Science, Edinburgh University, Scotland.
  51.