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. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
