On 15 September 2013 19:58, Martin Decky <[email protected]> wrote: > 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 .. > > True.
> 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. > > That is perhaps true for the functions currently in mainline. But I add a lot of functions that are not present in any file API. Functions like restrict(), lookup(), walk(), bind(), select()... open() even has completely different semantics from what it does now. read() and write() would both have unconventional arguments. That means prefixing all functions with a shared, unambiguous prefix is just common sense and avoids confusion. The entry barrier is inherently there because my VFS has unconventional interface, and I think prefix actually helps by enumerating all relevant calls in one place. > 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). > > The raw IPC wrappers in my case are quite difficult to work with without additional library support, and they are lower level than the trivial IPC wrappers currently in mainline. But as I said, it's trivial to expose them. > > 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. > > Implementation of bind(). Client-side implementation helps with memory and CPU accounting (per-client structures can consume unbounded amount of both, so implementing it client-side avoids concerns about malicious clients). Also, I expect that an extra layer of abstraction will help a lot by making the interactions of different operations more obvious. Server-side unions are not fun to debug, and I enjoyed a fair share of that. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
