On 15 September 2013 17:24, Martin Decky <[email protected]> wrote: > 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. > > As I see it, there are two cases:
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. > 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. > > 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. > > 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. > The software design point of view in this case is quite ambiguous I think. 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. > > 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). > > Point taken. I will move the files to a location more consistent with the rest of the library. > 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. > > Apology accepted. I apologize for being a dick about it. > 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. > > I will see what I can do about it. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
