Changeset 51ec40f in mainline for kernel/generic/src/ipc/ipcrsc.c


Ignore:
Timestamp:
2007-05-18T10:27:01Z (17 years ago)
Author:
Jakub Jermar <jakub@…>
Branches:
lfn, master, serial, ticket/834-toolchain-update, topic/msim-upgrade, topic/simplify-dev-export
Children:
f6d2c81
Parents:
ddf1255
Message:

Improve comments for the IPC subsystem.
Fix formatting and indentation.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • kernel/generic/src/ipc/ipcrsc.c

    rddf1255 r51ec40f  
    3535/* IPC resources management
    3636 *
    37  * The goal of this source code is to properly manage IPC resources
    38  * and allow straight and clean clean-up procedure upon task termination.
     37 * The goal of this source code is to properly manage IPC resources and allow
     38 * straight and clean clean-up procedure upon task termination.
    3939 *
    4040 * The pattern of usage of the resources is:
    … …  
    4848 * Locking strategy
    4949 *
    50  * - To use a phone, disconnect a phone etc., the phone must be
    51  *   first locked and then checked that it is connected
    52  * - To connect an allocated phone it need not be locked (assigning
    53  *   pointer is atomic on all platforms)
     50 * - To use a phone, disconnect a phone etc., the phone must be first locked and
     51 *   then checked that it is connected
     52 * - To connect an allocated phone it need not be locked (assigning pointer is
     53 *   atomic on all platforms)
    5454 *
    5555 * - To find an empty phone slot, the TASK must be locked
    5656 * - To answer a message, the answerbox must be locked
    5757 * - The locking of phone and answerbox is done at the ipc_ level.
    58  *   It is perfectly correct to pass unconnected phone to these functions
    59  *   and proper reply will be generated.
     58 *   It is perfectly correct to pass unconnected phone to these functions and
     59 *   proper reply will be generated.
    6060 *
    6161 * Locking order
    … …  
    6363 * - first phone, then answerbox
    6464 *   + Easy locking on calls
    65  *   - Very hard traversing list of phones when disconnecting because
    66  *     the phones may disconnect during traversal of list of connected phones.
    67  *     The only possibility is try_lock with restart of list traversal.
     65 *   - Very hard traversing list of phones when disconnecting because the phones
     66 *     may disconnect during traversal of list of connected phones. The only
     67 *     possibility is try_lock with restart of list traversal.
    6868 *
    6969 * Destroying is less frequent, this approach is taken.
    … …  
    7272 *
    7373 * *** Connect_me_to ***
    74  * The caller sends IPC_M_CONNECT_ME_TO to an answerbox. The server
    75  * receives 'phoneid' of the connecting phone as an ARG3. If it answers
    76  * with RETVAL=0, the phonecall is accepted, otherwise it is refused.
     74 * The caller sends IPC_M_CONNECT_ME_TO to an answerbox. The server receives
     75 * 'phoneid' of the connecting phone as an ARG3. If it answers with RETVAL=0,
     76 * the phonecall is accepted, otherwise it is refused.
    7777 *
    7878 * *** Connect_to_me ***
    79  * The caller sends IPC_M_CONNECT_TO_ME, with special
    80  * The server receives an automatically
    81  * opened phoneid. If it accepts (RETVAL=0), it can use the phoneid
    82  * immediately.
    83  * Possible race condition can arise, when the client receives messages
    84  * from new connection before getting response for connect_to_me message.
    85  * Userspace should implement handshake protocol that would control it.
     79 * The caller sends IPC_M_CONNECT_TO_ME.
     80 * The server receives an automatically opened phoneid. If it accepts
     81 * (RETVAL=0), it can use the phoneid immediately.
     82 * Possible race condition can arise, when the client receives messages from new
     83 * connection before getting response for connect_to_me message. Userspace
     84 * should implement handshake protocol that would control it.
    8685 *
    8786 * Phone hangup
    … …  
    8988 * *** The caller hangs up (sys_ipc_hangup) ***
    9089 * - The phone is disconnected (no more messages can be sent over this phone),
    91  *   all in-progress messages are correctly handled. The anwerbox receives
     90 *   all in-progress messages are correctly handled. The answerbox receives
    9291 *   IPC_M_PHONE_HUNGUP call from the phone that hung up. When all async
    9392 *   calls are answered, the phone is deallocated.
Note: See TracChangeset for help on using the changeset viewer.