Hi Jiri, thanks for elaborating on your ideas, see my comments below.
On 15.10.2012 22:07, Jiří Zárevúcky wrote: > Firstly, let me explain, “why nodes”. > The current VFS server internally keeps state as a “VFS triplet”. It > is basically an exact address of the file in currently running VFS > (server + file system driver). Outside the server, clients refer to > files using their filenames. Simple enough. In general, the clients are using file names only to get a file handle. Once the client has the file handle, the file name can both disappear (unlink) or change (rename). The file name is not important at all when you have a handle. > That means the most reasonable > approach is to deal with nodes the same way we deal with open files - > passing an index into a client-local table, that is managed > dynamically. ... > With file-descriptor-like handling comes an analogous problem of > passing nodes between processes (as has been noted before, acquiring > node becomes the only mechanism to access a file). The current VFS > server uses a generic mechanism for brokering a change in externally > managed state (for file descriptors), and this mechanism can be > utilised exactly the same way with nodes. This is basically how capabilities work. Client-local file handles are merely a specialization of this principle. In my view, we should either reuse (and, if needed, redefine the meaning of) file handles, or introduce a generic mechanism for capabilities so that we don't end up with dozen specializations of the capability mechanism. Another already existing specialization is IPC phones. > Jakub J. noted that if the handling of references to both is so > similar, we can just as well unify them in some ways, so we don’t have > two distinct mechanisms for essentially the same thing. > Well, after thinking about it for some time, I must say that we don’t > even need VFS to deal with two different types of objects, but more > about that later. Ok, let's see. > Next idea: No file descriptors, just nodes. What would the local node identifiers be? Integers? If so, that's effectively what file handles are. We don't really need to support POSIX read/write() on the VFS level (even now, as discussed during the last project meeting) and provide only pread()/pwrite() (coincidentally also POSIX), because that's what the VFS_OUT_READ/WRITE actually does. The only problem remains access mode which you address in the final idea below. > Final idea: > Just nodes as before, but no violation of the interface abstraction > through type checking. Instead, there is both OPEN and CLOSE operation > on a node, but instead of returning anything, it manages a > client-local counter of access “intentions”. As long as there have > been any calls to OPEN not yet matched by CLOSE, the node can be used > for I/O. This keeps the simplicity of only dealing with nodes in VFS > server, allowing to implement the stream metaphor purely in libc, > while keeping track of clients that read and write contents. So you want to keep the access information in the client-local table of ID's that identify nodes. Or do you rather want to allocate a separate per-client state for each node? > So there you have it, a single conceptually simple kind of object > exposed by the VFS server, leaving libc to implement the UNIX API if > we want to (though I’m utterly convinced we can do better). If I understood your proposal correctly, you are basically suggesting: - stop using term file handle, but continue to use the underlying principle to refer to file system nodes (both open and other types) - remove the position pointer from the file/node table and leave it in libc; VFS will cease to support read/write/lseek() directly on the client side of its interface and will support only an equivalent of pread() and pwrite() - the intention counter will distinguish an open node from other kinds of nodes; and will specify the exact access mode for a given client ID for the node - the file/node table will in fact be a table of tuples (intention counters, vfs_node_t *) or it will be a table of vfs_node_t *, but each vfs_node_t will have to track client intention counters individually; you may or may not want to get rid of one level of indirection which now exists in the file descriptor table If this is correct, I think it represents certain unification or even simplification of VFS (and at the same time more complexity for libc), but the basic principles remain in place. It's more like that you don't like to call the node IDs file handles, but they are essentially the same or at least very similar thing. I may have misunderstood where you want to store the intention counters, but it does not really change that much, IMHO. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
