Ok, then I will just point out that using standardized names for non-standard functions is IMHO a very bad idea, and makes working with HelenOS more difficult with questionable benefit.
Objection noted. In this particular case that we are talking about the benefits of such an arrangement IMHO outweigh the drawbacks, because it makes working with HelenOS much easier with only negligeable limitations.
If someone wants full standard compliance (including all the corner cases and semantics), there is libposix for it.
The low-level API is not supposed to be used by anything else than a higher-level API.
In many cases yes. But there is still the possibility of using the low-level API directly if you only want to do something simple or you want the control.
Think of it like the library implements some things that could just as well be in the server, but aren't, because the code is much simpler if it's on the client side.
In my opinion the simplicity of the code should not be the guiding rule. The guiding rule should be where the code should belong to from the software design point of view.
And this is the reason why I vote for the simple low-level file API using only a plain file descriptor. Because the handle to the stream of bytes is the only thing a plain simple client is concerned with. You generally should not pass any responsibility of the server to the client if the client is not concerned with the responsibility.
Well, I have not been here when the decision to mix everything up in libc was made, but I can't believe the reasons were serious enough to warrant such a confusing library.
This is not a question of a belief. The decision was made. If you want to change everybody's mind, split the libc properly, consistently and entirely and demonstrate the benefits. Starting with a single inconsistent exception is just not the way to go (IMO).
Honestly, I don't see the difference.
I am not proposing to treat a non-file as a file, I am proposing to treat a file as a specialization of a generic object the "inbox" could record and pass. Still no clue? Remember your OOP classes. Not making the file a polymorphic type, but making the "inbox" into a generic container (supporting, among others, also the files).
You could have asked why I chose to do it like this, instead you chose to call most of my free time for a last month "a joke". I am unable to respond positively to that. I really cannot.
All right, I acknowledge that calling it "a joke" was uncalled for. I apologize.
But for the record, I sort of understood your reasons (you actually described them in your email). I simply don't think that the reasons really justify the result: Replacing a perfectly working API that is spread into almost every user space task with a new one that has almost the same signatures and functionality, but no observable benefits.
If I were you, I would have approached it much more conservatively and tried to keep the API intact as long as it is viable (even by introducing some compatibility wrappers). Just for the sake of minimizing any conflicts and regressions by the upstream merge.
M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
