On 18 October 2012 09:52, Jakub Jermar <[email protected]> wrote: > 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. > > In any case, this increasingly starts to look like a > terminology issue, making it not that important in the end. > > [...] > 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. >
Terminology is unimportant. They are still file descriptors, but from the interface perspective, they represent a different object. Judging by the set of methods provided by IPC, HelenOS file descriptor is a seekable stream, and not a file. You may think of it differently, since you implemented it, but looking from the outside, it is different. I make no assumptions about the wiring that is inside, it is unimportant. IPC interface is the only defining characteristic (unless you have an actual specification of the internal meaning of file descriptors VFS provides at the interface, which I didn't read by some mistake). Everything not reflected in IPC interface falls into implementation-detail-that-can-change-anytime category. Otherwise, I have absolutely no way to know what you consider to be a property of the system, and what is truly just an implementation detail. And as I've written numerous times in my last message, the different name has the sole purpose of not being confusing, because from the interface point of view, it is a different thing. In the end, it's not even important. We are arguing about my views on your original implementation, while we should argue about your views on my proposed architecture; never mind names, renaming stuff is *easy*. So, please, once again, I'm discussing the services the new VFS server should provide to the outside (and be practically used by clients, while not being a confusing mess conceptually). -- Jirka Z. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
