On 16 September 2013 23:14, Jakub Jermar <[email protected]> wrote: > On 09/16/2013 08:02 PM, Jiří Zárevúcky wrote: > > On 16 September 2013 16:03, Martin Decky <[email protected] > > <mailto:[email protected]>> wrote: > > > > I don't really care about the actual prefix. All of file_*, > dir_*, > > vfs_*, vcl_* are fine with me. > > > > > > I do care, but obviously this is a matter of personal taste and the > > discussion can be endless. Thus anyone with mainline commit access > > has the liberty to merge anything he/she considers reasonable. > > > > And I have the liberty to alter the code later on if I don't > > consider it reasonable :) > > > > > > How about this: The pointer handle represents a generic filesystem node > > just for the purposes of navigating the client's local image of the > > hierarchy, but *_open() returns a numerical handle that is used in > > vfs_read(), vfs_write(), vfs_truncate(), etc. > > I.e. the functions operating on file's contents would be simple IPC > > wrappers, and the fat stuff is used just for navigating the file tree. > > > > Although, I can't figure out what would be a proper name and prefix for > > the "generic fs node" type. Both "file" and "dir" suggest a particular > > kind of file, and "node" or "tree" are both too non-obvious. > > Would not this defeat the orthogonality of the API? What if you want to > use the handle returned by *_open() for something else than operations > on the content (client-based binding comes to mind). To me, the API was > more beautiful than the Unix API, because there is a single object type > that all methods work with (not really important whether a numeric > handle or an opaque struct). > > You could still do all primitive vfs_ operations. I guess this way you wouldn't see the client side logic as a file access library, but rather as a client-side namespace management library. And of that, vast majority of users would only ever use one function for "lookup file X in my cwd".
-- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
