home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0005.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  1.9 KB
  1. From:  Doug Gwyn <gwyn@smoke.brl.mil>
  2.  
  3. In article <692@longway.TIC.COM> peter@ficc.ferranti.com (Peter da Silva) writes:
  4. -> SVID 3 (System V Release 4.0), OSF AES (OSF/1), Berkeley BSD 4.4, MACH
  5. -> 2.5, ULTRIX, SunOS, HP/UX, etc, all include an (almost) identical
  6. -> definition of mmap() based on the current Sun/Berkeley specification.
  7. -V.3.2 does not include this interface, and V.3.2 is going to be around,
  8. -and in fact very common, for at least a couple of years to come. A standard
  9. -that locks out V.3.2 is going to hurt portability.
  10. -I believe that implementing shared memory in terms of memory mapped files
  11. -is a good thing, and that every effort should be made to encourage it...
  12. -within reason. Preventing the implementation of POSIX shared memory on
  13. -the largest installed base of UNIX systems in existence is not within
  14. -reason.
  15.  
  16. The goal of POSIX was not to bless existing botched implementations!
  17. 4.3BSD also does not provide a working mmap(), and it also fails to
  18. comply with 1003.1 in numerous ways.  This is being addressed by making
  19. a future release (4.4BSD) POSIX-compliant, not by making 1003.1 cater
  20. to existing deficiencies.  Similarly for the real-time extensions.
  21. If 1003.1 had had to avoid making implementors improve their products,
  22. it would have been of even less practical use than the /usr/group 1984
  23. standard.
  24.  
  25. -    a) People with "real mmap" will end up using more than the
  26. -       standard allows. This is a pretty simple prediction... look
  27. -       at existing extended implementations.
  28. -    b) People with the "fake mmap" will end up blowing the extra
  29. -       parameters, "safely". Then when run on a system with the real
  30. -       thing their programs will fail.
  31.  
  32.     c) People who are concerned with portability with not stray
  33.        outside the domain that the standard guarantees to work.
  34.  
  35. You seem to be arguing that extensions should be prohibited.
  36.  
  37. Volume-Number: Volume 20, Number 6
  38.  
  39.