On 10/17/2012 07:06 PM, Jiří Zárevúcky wrote: > On 17 October 2012 17:53, Jakub Jermar <[email protected]> wrote: >> On 17.10.2012 17:27, Jiří Zárevúcky wrote: >>> Yes. The problem is that the "file handles" we have now are not just >>> references to files. They are complete active IO streams built on top >>> of files. That is a lot of unnecessary assumptions about how we use >>> files. >> >> I still think you are trying to see file handles as something more than >> they are. Their current uses: >> >> - client-local names for file system nodes that are independent of >> human readable file system names and paths >> - holders of references to the underlying nodes >> - yes, they are associated with an IO position pointer, but that can be >> removed and they will still be considered file handles, even in >> today's VFS >> - yes, they are associated with access mode information, but you want >> to preserve that >> - they are used to implement standard C FILE and DIR streams in libc, >> but so will be your node handles >> >> So what is the clutter that you see besides the position pointer? >> > > Forgive me if I'm wrong, but are you talking about how file handles > work within the VFS server? As far as I know, there is no way to > simply get a handle for a file at a path. You actually have to open it > for read or write, complete with signalling the filesystem the file > has been opened. When you use handles only as handles, you > specifically want the lookup not to open the file in any way. > As far as I know, the current IPC interface doesn't support this kind > of use, and while you can argue the actual implementation could be > extended with little effort, I don't think that is even relevant in > context of this discussion.
Well, until now, open() has been sufficient for mapping a pathname into a file handle. In HelenOS, implementation tends to be driven by current need so other mechanisms don't exist because they were not needed. That does not mean that if they existed, we would need to rename file handles to something else. In any case, this increasingly starts to look like a terminology issue, making it not that important in the end. However, if you remember one of the LWN articles [0], it suggests using file descriptors for unexpected things, such as to represent a mounted file system before it is bound to the namespace. The article also suggest the possibility to split open() into a part which just gets you a file descriptor and another call which will make it ready for IO. I can see a direct relation to what you are suggesting in it, yet the Linux guys can still admit that they are working with file descriptors. Jakub [0] http://lwn.net/Articles/412131/ _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
