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.
That's a good point. So how about keeping the vfs_ prefix for the really low-level functions (most of them will probably stay private) and use some really intuitive object prefix(es) for the intended public API?
Say file_ for file functions, dir_ for directory functions, etc.? I know, it's also not perfect, but it's (IMO) better than a cryptic acronym such as vcl_.
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.
Sounds good. Without the actual code the debate is mostly academic, me fighting for the conservative side and Jiri fighting for the progressive side :)
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
