home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 167 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From jsq@cs.utexas.edu  Tue Oct  2 13:58:40 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA25842; Tue, 2 Oct 90 13:58:40 -0400
  4. Posted-Date: 2 Oct 90 16:16:54 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: donn@hpfcrn.fc.hp.com (Donn Terry)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <13103@cs.utexas.edu>
  10. References: <556@usenix.ORG> <557@usenix.ORG> <106697@uunet.UU.NET> <566@usenix.ORG> <107020@uunet.UU.NET> <107042@uunet.UU.NET>
  11. Sender: jsq@cs.utexas.edu
  12. X-Submissions: std-unix@uunet.uu.net
  13. Date: 2 Oct 90 16:16:54 GMT
  14. Reply-To: std-unix@uunet.uu.net
  15. To: std-unix@uunet.uu.net
  16.  
  17. Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
  18.  
  19. I was thinking about this a bit more, and want to propose some food for
  20. thought on the issue.
  21.  
  22. Classically, open() is a function that "opens a file descriptor", which
  23. is where the name comes from.
  24.  
  25. However, if you think, rather, of open() as "translate from the (filesystem)
  26. namespace this string, and give me a handle on the object" it actually makes
  27. more sense.
  28.  
  29. The operations that can be performed on a file are the classical operators
  30. applicable to such a handle.  However, some are forbidden or meaningless on 
  31. some object types (lseek on FIFOs, ioctl on ordinary files, some fcntls on
  32. devices), and some have operations only applicable to them (ioctl on 
  33. devices) and no other type.  I can easily imagine an object that had none
  34. of the classical file operations applied to it.
  35.  
  36. Now, there is also nothing that requires that open() be the only function
  37. that returns such a generic object handle.  Imagine (simple example) a
  38. a heirarchical namespace that contains all possible character
  39. bitcodes in the namespace.  Open() would not work very well because of the
  40. null termination and slash rules.  However, I can imagine another function
  41. that takes a char** as an argument, where each element is the name in
  42. the next level of the heirarchy.  (With length in the first byte.)  It
  43. would still return a classical file descriptor.  Similarly, maybe the
  44. punctuation is different, or the notion of "root" is different; generalizing
  45. open() to "give me a handle in a namespace" may be most useful.
  46.  
  47. I intend this not as any sort of proposal of something that should or should
  48. not be done, but as an "icebreaker" in terms of thinking about the problem.
  49.  
  50. What are the further generalizations we need, how do they make sense and
  51. fit together, and (the real test of success) what are some of the unexpected
  52. benefits of the generalization?  (Granting that the "biggest" unexpected
  53. benefit will show up "later".)
  54.  
  55. Donn Terry
  56. Speaking only for myself.
  57.  
  58. Volume-Number: Volume 21, Number 167
  59.  
  60.