On 20.9.2013 3:30, Jiří Zárevúcky wrote: > On 20 September 2013 00:09, Martin Decky <[email protected] > <mailto:[email protected]>> wrote: > > scheduler is completely cooperative, and "managers" are just fibrils > that handle IPC events and for some reason are treated specially. > > > Well, you have an interesting way how to approach things -- > dismissing everything that is not immediately clear to you as too > complicated, probably broken and a target for your next rewrite. [...] > > > Now you are just trying to make it personal. I have asked you to point > out what part of my understanding of the system is incorrect. You have > not done so, and instead you are trying to question my interest in > improving things. Surprisingly to you, most parts of HelenOS are not > designed by God and sheer personified perfectness, and I am trying to > improve things that come across as problematic to me. Structuring of > fibril/async implementation, which currently mixes together an > implementation of four conceptually independent subsystems, is one such > place of interest. > > > > > The manager fibrils are treated specially because they are special, > from the software architecture point of view. They are deliberately > set aside because they do something else than implementing the > business logic of the task. Whether that means that they have > relatively little to do right now is not so important. > > > Let me make myself more specific then. I believe the software > architecture in this case is flawed, it makes things confusing, and > limits future possibilities for improvement (because nobody will touch > the tangled mess). > > > > [...]totally and utterly unrelated to your original goal, which is > getting your VFS2 stuff integrated. Aren't you just totally losing > focus? > > > You have told in an earlier message you have about 20 different branches > at a time. Including this thing, I am working on 3. Does that means you > lack any kind of focus at all? I have to wonder. > > Unless you want to pay me to do what you want, please stop criticizing > the way I use my time. I can't keep focusing on the same thing for > months at a time, and just because I am working on some VFS stuff > doesn't mean it's my sole purpose in life to get it merged right this > minute. > > > > Since currently managers do > nothing to solve this, I don't see what is the problem you are > getting at. > > > Yes, currently they don't. But they might be quite handy when they > start doing it. > > > Allow me to point out they will not start doing it on their own. > Somebody has to make them. We may have radically different view of what > the final state should look like, but where I try to actually improve > the implementation and realize my view, you are just pointing out the > blatantly useless facts of how perfect the current code would be if it > "started" doing all this wonderful stuff. > > > > It is really not in my nature to limit people in their initiative > and I appreciate any discussion with you about how things could be > improved. But in my personal opinion you are now switched to a mode > where you tend to rewrite everything you touch only because you > simply don't appreciate how it is done now. > > You are just fixing things that are not broken. > > > How about this? There was nothing broken with living in a cave and > hunting antilopes to survive. Yet we are not doing it anymore. It's > called progress. Things that are not broken have the problem that to > different people, different things look broken. If you personally are > perfectly comfortable with the way something works now, don't take it to > mean there is no space for improvement. > > > > If you don't get your focus under control, next week you'll be > writing to Intel about the problems of the IA-32 instruction set :-D > > > My focus is all right, thank you. I do have a bunch of ideas stored for > various HelenOS code for when I find the time. I have been putting off > this fibril discussion for more than a year, maybe I will start > discussing another potential improvement in another year or so.
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. 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. Can you see that this entire sequence of events is motivated by only one thing: your wish to use a very specific synchronization in your VFS2 code? Surely, the fibril synchronization and the async framework can use some face lift, but this can be done now or after the VFS2 integration, as an isolated change, preserving the current building blocks. Another example of this domino effect is the case with the linked list. Instead of using what every other function in HelenOS uses (the basic building blocks), you insist on sticking with your current VFS2 code and even suggest that the rest of HelenOS should change. (*) This has never been a goal. There is no meaning of having fibrils without the async framework and vice versa, just as there is no meaning of having a scheduler without threads. These two entities can be somewhat isolated (the split into fibril.c and async.c), but they are still mutually interwined. Fibril synchronization is used by the fibrils, but builds on async framework basic blocks, so it needs to have some knowledge of the async framework (doesn't really matter whether the knowledge is abstracted away to some function in fibril.c, fibril_synch.c or not at all). Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
