I actually tried to replace atomics with locks yesterday, but it resulted in inexplicable failures, which was reason enough for me to leave it as-is for the moment. Still, I would have nothing against the change if it worked.
Well, this definitively calls for a deeper analysis. "There is something wrong with the locks" cannot be just ignored ..
But HelenOS API is non-standard. There is no point denying that.
Nobody does that. But there is also no point in overstressing it. POSIX systems also don't stress in any way that they are not Win32 compliant. POSIX is simply not relevant to us (except libposix), as well as Win32 isn't. A large part of POSIX deals with entities we don't even plan to implement.
To me, lack of consistent directory structure is a major flaw, and freely mixing standardized and non-standard headers and functions is the only reason why libposix is so ugly implementation-wise.
There are no standardized headers in HelenOS (again only except the headers from libposix that might eventually aspire for that title). IMO the reasons for the uglyness of libposix are (as you often point out) the limitations of the C toolchain.
Either you don't want to use POSIX functions. Then I don't see any reason why we can't use a different name to make the difference obvious. It's a few extra letters, and you don't type these names so often that it makes difference. On the upside, it would make implementation of libposix, and in general porting POSIX applications, much easier. The other possibility is that you want to use POSIX functions. In that case, you should not depart from their standardized semantics.
There is actually a third possibility: Just imagine there is no POSIX. It's easy since it is in no way relevant to HelenOS (except libposix). The open/read/write/close is just a common file API implemented by a countless number of OSes and programming environments, in most cases also not in a 100% POSIX compliant way.
It is an API instantly recognizable and since our implementation behaves reasonably similar to all the compliant and non-compliant implementations in the wild, it helps lowering the entry barrier.
If you really really insist on renaming the functions, please at least use the prefix vfs_.
Then it's possible to simply extract and make publicly accessible the low-level "_vfs_" functions. I don't see why someone would want to use them, but it's easy to make that possible.
Hold on. In mainline, functions such as open(), close(), read(), etc. are essentially nothing more that the plain IPC calls. The current implementation of them is exactly what you suggest to export! They are the low-level VFS functions that I would like to preserve (dealing with streams of bytes identified by a handle), nothing more than trivial IPC wrappers. And they are actually being used (that's for the "reason" part).
And the expected benefits (including but not limited to: much easier reasoning about server behavior and file accessibility) of moving some functionality to the client would easily outweigh any conceptual design guideline.
Could you be more specific? What specific reasoning about server behaviour and file accessibility? I just fail to imagine any examples that would yield the benefits of a client-side implementation.
I apologize for being a dick about it.
No problem :) This is still a friendly chat compared to any regular discussion in the linux-kernel mailing list :D
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
