On 16 September 2013 12:58, Martin Decky <[email protected]> wrote: > Seriously, I think reverting to support also the old API for the sake of >> compatibility with its own former self is the wrong way to go. Now, lots >> of Unixisms that should only be part of libposix will continue to be >> part of our libc and the confusion about how much it actually is and is >> not POSIX will go on. I still don't get it why should we still provide a >> POSIX-similar interface in libc, when there is a clean generalization >> and purification available? >> > > Well, perhaps I pushed too hard on this .. > > What I really disliked was the cryptic vcl_ prefix and the abandonment of > a single plain file handle as the open file identifier. > > My objections to the change of the base names and arguments of the > functions was collateral -- if this is really justified for the future > development of VFS2, I can live with that. > > How about a compromise? Use the base names as Jiri suggested originally, > but use the vfs_ prefix (I really think this is important for the intuitive > recognition of the functions) and possibly the single file handle where > appropriate? > > I think both of those would actually be more confusing. Using vfs_ prefix for a library that does more than just wrap VFS would be equivalent to using ipc_ prefix for the entire async framework. Even more so if under the same prefix there are functions with raw numerical handle and functions with pointer handle.
Right now, I don't know what is the right solution. I will have to first implement the stuff that actually uses client-side data, so that we all have a clear idea of how the handles are used in different functions. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
