home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.12 / text0005.txt < prev    next >
Encoding:
Internet Message Format  |  1989-01-07  |  2.6 KB
  1. To: John Gilmore <hoptoad.UUCP!gnu@cgl.ucsf.edu>
  2. Cc: std-unix@sally.utexas.edu, utzoo.UUCP!henry@cgl.ucsf.edu
  3. From: Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>
  4.  
  5. I explained what the problem was with McKusick's implementation
  6. and why both AT&T and IEEE 1003.1 decided to do it differently.
  7. I also provided a public-domain package that can be built for
  8. use on Berkeley-based systems, so the POSIX interface is
  9. available there, too.  However, it is simply not practical for
  10. most vendors to provide the Berkeley interface in a true System
  11. V environment (more on this later).
  12.  
  13. You keep making noises that sound like you think there is a
  14. conspiracy to reject correct Berkeley designs for various things
  15. in favor of inferior approaches.  I've been at least peripherally
  16. involved with almost all those situations, and that simply is not
  17. what happens.  The real problem is that Berkeley keeps coming
  18. out with stuff that has design or compatibility problems that
  19. other people have to figure out how to fix later.  Such fixes
  20. are not gratuitous changes to perfect designs!
  21.  
  22. You probably don't notice the problems because you work in a
  23. Berkeley-based environment.  Try building some of your code on
  24. real SVR2 systems some time and see what you break when you
  25. change SVR2 to use the Berkeley <sys/dir.h> -- your code would
  26. then work but there are a LOT of existing programs affected by
  27. that incompatible change.  Real-world vendors have to accommodate
  28. existing (pre-BFS/NFS) code that did the best it could under
  29. prevailing circumstances while providing improved, portable
  30. support for future applications.
  31.  
  32. I ran head-on into this directory issue when I ported UNIX
  33. System V (user mode) onto 4.2BSD.  My solution was to throw out
  34. <sys/dir.h> altogether, and provide (McKusick-compatible)
  35. directory access functions for the System V environment.  The
  36. reason I could do that was that I was in total charge of all
  37. software to run in that environment.  When we started importing
  38. code, the absence of <sys/dir.h> is the only thing that saved us
  39. from wasting valuable time tracking down obscure bugs.  Vendors
  40. that might have tried such an approach would have upset their
  41. existing customer base.
  42.  
  43. My older package served as the basis for the one in SVR3, which
  44. was modified by AT&T to conform to POSIX, which by then had
  45. already identified the problem with using <sys/dir.h> and/or
  46. (struct dirent) for the portable directory interface.  I fully
  47. support the POSIX choice of names as a correct decision.
  48.  
  49. Until we get 4.4BSD (or whatever) into POSIX compliance, simply
  50. build my PD package for BFS and use it with your portable code.
  51.  
  52. Volume-Number: Volume 12, Number 6
  53.  
  54.