On 20 September 2013 13:09, Jakub Jermar <[email protected]> wrote: > On 20.9.2013 12:34, Jiří Zárevúcky wrote: > > > > On 20 September 2013 12:01, Jakub Jermar <[email protected] > > <mailto:[email protected]>> wrote: > > > > I believe Martin didn't want to discourage you from contributing to > > HelenOS. Neither do I - it is perfectly okay if you try to improve > > various areas of HelenOS. But let's also consider the motivation > behind > > and the need for various changes. > > > > In this debate, we are faced with something that could be described > as > > an undesirable domino effect, which is sending tectonic waves > throughout > > the system. > > > > It starts with an isolated problem, VFS2 in this case. There you > devise > > a specialized low-level synchronization primitive for the > implementation > > of pipes, which you claim is impossible to implement using the > standard > > primitives. After receiving some doubts and criticism from us about > not > > using the basic building blocks and having a low-level primitive in > the > > VFS code, instead of adjusting your VFS2 code accordingly, you > decide to > > build all fibril synchronization on your new synchronization > primitive. > > This is basically a device allowing you to keep your VFS pipe code > as it > > is, instead of rewriting it using the ordinary synchronization. > > > > > > No, this is completely wrong. I have already rewritten the VFS pipe code > > to use ordinary synchronization, and I am not pushing it until I have > > properly tested it. > > Just describing how it looks like. This is probably the first time you > are mentioning this here. > > Point taken.
> > But why > > not - the related cleanup seems nice and reasonable. There is only > one > > problem with it: the timeouts, which can only be done using the async > > framework or a separate thread (which is quite cumbersome). So the > > fibril and async framework separation (*) and cleanup cannot be > entirely > > accomplished and therefore you suggest to rewrite the async framework > > completely. > > > > > > If you read my first message of this thread, you will notice that I > > suggested rewriting async framework to begin with. In fact, I explicitly > > said that for fibril_synch, this cleanup doesn't do much, but for async > > framework, simplification could have bigger effect. If all your > > interpretation of my work stands of mistaken ideas about my motivation, > > this is going nowhere. > > I am still interested in seeing where this goes. But you need to > understand that without the knowledge of your challenge (which is > obviously not your fault, but mine), these changes seem quite arbitrary > and one wonders about the motives. The connection with VFS2 where you > first used it comes naturally to mind. > Yes, I suppose it does. You should understand that my first and foremost goal is to improve HelenOS in the areas I perceive as flawed. This includes VFS2, but redesigning VFS is not a goal in itself. It's a non-trivial part of the overall goal, but just a part nonetheless. That means I am fully within my area of focus if I take an occasional detour into some simpler problem. This includes my dislike for <adt/list.h>, which I admittedly shouldn't have brought forward so strongly while discussing VFS2. This also includes the fibril-async-ipc cluster, which I believe can be improved significantly by delegating lesser fibril scheduling to a self-contained unit, independent of the problems I am trying to solve in VFS2. Whether or not I am correct, or even understood, in my proposed changes, is the only problem that should be discussed here. To put it bluntly, my central motivation for anything is none of anyone's business, and discussing my goals and focuses---instead of your disagreement with me---is one of the more pointless things you could do here. There should be some kind of discussion guideline, like "If you disagree with someone, be relevant to the question at hand, and don't try to prove the question itself unjustified by appealing to his motives". -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
