In mainline,1665 I have integrated my changes to the kernel IPC subsystem. The work is not yet entirely finished, but I decided to merge what I have now because I believe it is reasonably stable and complete. The kernel should work just as it did before the changes, but much better. As previously announced, the main changes I wanted to achieve are the following:
- possibility for the caller to "forget" the call if it has not already been answered by the callee; each call is either forgotten or answered, but never both - the caller does not wait for forgotten calls so if the callee is holding up the answer for some reason, it will not prevent the callee from completing its IPC cleanup and destruction - the caller must still wait for all answered calls, but since those are by definition answered, the answer will be delivered to caller's answerbox soon, without any further delays - the callee is still expected to attempt to answer all calls; it will either succeed or cleanup the call; forgotten calls are basically donated to it by the caller Besides of that and as a by-product of the above, I have also performed some nice code cleanup and fixed several bugs I noticed along the way: - I formalized the notion of method-specific hooks that were executed as part of request_preprocess(), process_request(), answer_preprocess() and process_answer() message processing and factored these away into dedicated files and ops structures. The result is much smaller sysipc.c and a couple of new files in generic/src/ipc/ops that contain all the new callbacks broken down by the method type. It should be much easier now to write the callbacks because everything pertaining one method type can be found in one file, in the natural order of execution. - I removed several ad-hoc short cuts and deviations from the standard code flow through the IPC callbacks and thus fixed various inconsistencies and kernel memory leaks; however, there are still several remaining possibilities when some callbacks may be skipped due to circumstances. Some of these can be addressed while some can be only documented and the callbacks need to be designed with this in mind. - I noticed and fixed two problems with either IPC_M_CONNECT_TO_ME and IPC_M_CONNECT_ME_TO when these connection-establishing calls were answered by the callee when the caller was already beyond a certain point in its IPC cleanup. - Previously in answer_preprocess() when the return value was EHANGUP, the kernel slammed the phone which last either sent or forwarded/masqueraded the call. The problem with the latter case was that the forwarder was not necessarily still alive at that time. I changed the behaviour to always slam the caller phone, which is guaranteed to still exist in that context. However, the philosophical question is what should be the right course of action when the call is forwarded. Shall we shoot the messenger or rather the real sender? Or nobody? The callee probably wants to close that specific phone which delivered the call which it now answers with EHANGUP. The problem is that in general we don't know what phone was used for delivery, especially when the call is forwarded. And even if we knew it, slamming the forwarder may not be the right thing to do. The forwarder may be just acting on behalf of several of its clients without a real understanding of the meaning of the forwarded call. Conversely, slamming the original sender may not be the right thing to do either as the call may have been altered by one of the forwarders and thus the sender is completely innocent of any reasons that lead the callee to slam the connection. If the call is forwarded, shall we do rather nothing? In the world of parallel async sessions, slamming any phone will result in a surprise in the form of an immediate EHANGUP that will be returned to a random future async exchange depending on who is "lucky" to be given the slammed phone. - I noticed that a call's sender was always the task which allocated the call structure. This is usually a correct choice, but not always. Sometimes the kernel wants to send a call (eg. IPC_M_PHONE_HUNGUP in kbox clenaup) on behalf of another task and then things start to break. I changed this so that the sender is derived from the information found in the sending phone. Both comments and bug reports will be welcomed. Comments to this ML, and bug reports to trac please. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
