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()...
Fine. But I am not talking about the new functions.
open() even has completely different semantics from what it does now.
This still allows you to name this new function differently and keep the old open() as a compatibility wrapper.
read() and write() would both have unconventional arguments.
You can either conservatively extend the arguments or reimplement the original read() and write() as wrappers.
For the trivial (but still common) use case of opening a file, reading some bytes from it and closing there is simply no reason for anything else -- you don't expect any new behaviour from the VFS, you have no new data to supply to the API, therefore you should not be required to explicitly supply any new arguments to the calls. All the internal changes can be masked and all you (as the end client) need is a single file handle.
That means prefixing all functions with a shared, unambiguous prefix is just common sense and avoids confusion.
OK, if the prefix is vfs_, I'll shut up :)
The entry barrier is inherently there because my VFS has unconventional interface
Yes, but this does not forbid you to keep the original API for the original use cases and naturally extend the API for the new use cases.
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).
The question is: Is this really the best solution? It is basically a trade-off between the proper separation of concerns and the ease of accountability.
It's hard to judge until I see the specific code, but I would still probably prefer the code without such ad-hoc trade-offs, with a clean separation of concerns and traditional accounting (e.g. trivial limits on the number of per-client resources). Per-client data poses a generic problem (the same pattern appears everywhere) which calls for a generic solution (such as the client-server resource lease like in Genode).
Server-side unions are not fun to debug, and I enjoyed a fair share of that.
Yeah, well, you probably won't agree with me, but the clarity of the final software design should not be sacrificed to ease the development effort on the server.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
