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