Index: kernel/generic/src/ipc/ipcrsc.c
===================================================================
--- kernel/generic/src/ipc/ipcrsc.c	(revision f5837524878dfa0cfbf12164f7b8144cee094f9a)
+++ kernel/generic/src/ipc/ipcrsc.c	(revision 8b6cd5cc7eb1fce2e87ead2a1403607213d545be)
@@ -31,99 +31,4 @@
  */
 /** @file
- */
-
-/*
- * IPC resources management
- *
- * The goal of this source code is to properly manage IPC resources and allow
- * straight and clean clean-up procedure upon task termination.
- *
- * The pattern of usage of the resources is:
- * - allocate a capability and phone kernel object (do not publish yet),
- *   connect to the answerbox, and finally publish the capability
- * - disconnect connected phone (some messages might be on the fly)
- * - find phone capability and send a message using phone
- * - answer message to phone
- * - hangup phone (the caller has hung up)
- * - hangup phone (the answerbox is exiting)
- *
- * Locking strategy
- *
- * - To use a phone, disconnect a phone etc., the phone must be first locked and
- *   then checked that it is connected
- * - To connect an allocated phone it need not be locked (assigning pointer is
- *   atomic on all platforms)
- *
- * - To answer a message, the answerbox must be locked
- * - The locking of phone and answerbox is done at the ipc_ level.
- *   It is perfectly correct to pass unconnected phone to these functions and
- *   proper reply will be generated.
- *
- * Locking order
- *
- * - first phone, then answerbox
- *   + Easy locking on calls
- *   - Very hard traversing list of phones when disconnecting because the phones
- *     may disconnect during traversal of list of connected phones. The only
- *     possibility is try_lock with restart of list traversal.
- *
- * Destroying is less frequent, this approach is taken.
- *
- * Phone call
- *
- * *** Connect_me_to ***
- * The caller sends IPC_M_CONNECT_ME_TO to an answerbox. The server receives
- * 'phoneid' of the connecting phone as an ARG5. If it answers with RETVAL=EOK,
- * the phone call is accepted, otherwise it is refused.
- *
- * *** Connect_to_me ***
- * The caller sends IPC_M_CONNECT_TO_ME.
- * The server receives an automatically opened phoneid. If it accepts
- * (RETVAL=EOK), it can use the phoneid immediately. Possible race condition can
- * arise, when the client receives messages from new connection before getting
- * response for connect_to_me message. Userspace should implement handshake
- * protocol that would control it.
- *
- * Phone hangup
- *
- * *** The caller hangs up (sys_ipc_hangup) ***
- * - The phone is disconnected (no more messages can be sent over this phone),
- *   all in-progress messages are correctly handled. The answerbox receives
- *   IPC_M_PHONE_HUNGUP call from the phone that hung up. When all async calls
- *   are answered, the phone is deallocated.
- *
- * *** The answerbox hangs up (ipc_answer(EHANGUP))
- * - The phone is disconnected. EHANGUP response code is sent to the calling
- *   task. All new calls through this phone get a EHUNGUP error code, the task
- *   is expected to call sys_ipc_hangup after cleaning up its internal
- *   structures.
- *
- *
- * Call forwarding
- *
- * The call can be forwarded, so that the answer to call is passed directly to
- * the original sender. However, this poses special problems regarding routing
- * of hangup messages.
- *
- * sys_ipc_hangup -> IPC_M_PHONE_HUNGUP
- * - this message CANNOT be forwarded
- *
- * EHANGUP during forward
- * - The *forwarding* phone will be closed, EFORWARD is sent to receiver.
- *
- * EHANGUP, ENOENT during forward
- * - EFORWARD is sent to the receiver, ipc_forward returns error code EFORWARD
- *
- * Cleanup strategy
- *
- * 1) Disconnect all our phones ('ipc_phone_hangup').
- *
- * 2) Disconnect all phones connected to answerbox.
- *
- * 3) Answer all messages in 'calls' and 'dispatched_calls' queues with
- *    appropriate error code (EHANGUP, EFORWARD).
- *
- * 4) Wait for all async answers to arrive and dispose of them.
- *
  */