On 15 September 2013 16:53, Jakub Jermar <[email protected]> wrote: > On 09/15/2013 02:24 PM, Jiří Zárevúcky wrote: > > On 15 September 2013 12:42, Martin Decky <[email protected] > > <mailto:[email protected]>> wrote: > > > > It has taken me a bit longer than I expected, but the current > > state of > > my repository is that it can be merged (modulo possible bugs), > and > > further additions won't have so much impact on the rest of the > > system as > > they had until now. > > > > > > Thanks for your email. I am sorry to disappoint, but in my opinion > > the branch is still far from being mergable into mainline. A few > > reasons for that: > > For the record, I was watching the changes closely until about two weeks > or so ago and I quite liked them. The whole series starts with a nice > cleanup/handlification of the interface and the code and it seemed > reasonable to me. Now, I still need to look at what was done in the most > recent changes. > > What I had reservations against and discussed it with Jiri was the > tendency to introduce unnecessarily sophisticated (and thus complex) > lockless synchronization in places where a simple mutex or an rwlock > would do. >
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. > > Also, why is the vcl_* stuff as the only thing in the "helenos" > > subdirectory of the libc? > > > > > > Because nobody else has thought of moving non-standard HelenOS specific > > functions into a separate directory, yet. > > Martin has a good point in his reply. HelenOS cannot consider itself > non-standard and a second-class citizen of its own libc, segregating > itself into some HelenOS-specific subdirectory. > > But HelenOS API is non-standard. There is no point denying that. Also, consider that libc is combining numerous independent IPC protocols and functionality in one shapeless library. 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. > On a related note, in your recent changes, you added a TODO to replace > the restarting automaton which canonifies paths with simpler code. You have a point. When I see something I do not like, I sometimes write down a TODO/FIXME, so that I can get back to it later. I probably shouldn't do that, but on the other hand, it's just a line of comment and can be removed. My problem with canonify() is that you can easily write that transformation in quarter the size of current code, and much more understandable (which is a similar reason to your dislike of atomics I think). But that is not specific/relevant to the branch at all. > > > You do understand that with all the response I am getting for various > > proposals here (which is, next to none), keeping this outside the > > mainline means more private changes I get absolutely no feedback on. > > Unless you guys actually participate in external branches, doing any > > work on HelenOS short of complete fork is pointless. > > > > You could have subscribed to my branch more than a month ago and dispute > > my changes as I was making them. Instead, you wait for me to say "I am > > happy with this" just so that you could say you don't like half of it. > > Not helping. > > As I said, I have been following your branch and providing feedback as > time permitted. I am now going to have a look at the rest of it. Thanks. Of course, it would help to get most of the essential missing > functionality back in the meantime and to test/fix the libposix use cases. > > I don't think there is anything essential missing, except for the tests perhaps. I will see what I can do about that. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
