Changes between Version 2 and Version 3 of IPC

2009-05-01T12:47:33Z (15 years ago)
Jiri Svoboda

Make use of L1 headings.


  • IPC

    v2 v3  
    1 == IPC for Dummies ==
     1= IPC for Dummies =
    33Understanding HelenOS IPC is essential for the development of HelenOS userspace servers and services and,
    1414 * [#IpcSkeletonSrv Writing a skeleton server]
    16 === Introduction to the runtime environment === #IpcIntroRT
     16== Introduction to the runtime environment == #IpcIntroRT
    1818The HelenOS kernel maintains a hospitable environment for running instances of user programs called ''tasks''.
    3434Fibrils were introduced especially to facilitate more straight forward IPC communication.
    36 === Basics of IPC communication === #IpcIntroIPC
     36== Basics of IPC communication == #IpcIntroIPC
    3838Because tasks are isolated from each other, they need to use the kernel's syscall interface for communication with the rest of
    5050of the caller task.
    52 ==== Asynchronous framework ====
     52=== Asynchronous framework ===
    5454If a task is multithreaded or even if it has only one thread but several fibrils, the idea of connection is jeopardized. How can the task tell which
    7070The benefit of using the asynchronous framework and fibrils is that the programmer can do without callbacks and state automata and still use asynchronous communication.
    72 ==== Capabilities of HelenOS IPC ====
     72=== Capabilities of HelenOS IPC ===
    7474The capabilities of HelenOS IPC can be summarized in the following list:
    8787on the data transfer or the memory sharing, respectively.
    89 === Connecting to another task === #IpcConnect
     89== Connecting to another task == #IpcConnect
    9191A HelenOS task can only communicate with another task to which it has an open phone. When created, each task has one open phone to start with. This initial phone is always connected to the naming service. The naming service is a system task at which other services register and which can connect clients to other registered services. The following snippet demonstrates how a task asks the naming service to connect it to the VFS server:
    111111The client uses the ''ipc_hangup(int phone)'' interface to close the connection.
    113 === Passing short IPC messages === #IpcShortMsg
     113== Passing short IPC messages == #IpcShortMsg
    115115On the lowest level, tasks communicate by making calls to other tasks to which they have an open phone. Each call is a data structure
    180180In this example, ''rid'' is the hash of the received call, ''EOK'' is the return value and ''fd'' is the only return argument.
    182 === Passing large data via IPC === #IpcDataCopy
     182== Passing large data via IPC == #IpcDataCopy
    184184Passing five words of payload in a request and five words of payload in an answer is not very suitable for larger data transfers. Instead, the application can use these
    193193In theory, the programmer can use the low-level short IPC messages to implement all three phases himself. However, this is can be tedious and error prone and therefore the standard library offers convenience wrappers for each phase instead.
    195 ==== Sending data ====
     195=== Sending data ===
    196196When sending data, the client is the sender and the server is the recipient. The following snippet illustrates the initial phase on the example of the libc ''open()'' call which transfers the path name to the VFS server. The initial phase is also the only step needed on the sender's side.
    240240of ''ipc_data_write_finalize()''. If it is non-zero, then there was an error.
    242 ==== Accepting data ====
     242=== Accepting data ===
    244244When accepting data, the client is the recipient and the server is the sender. The situation is similar to the previous one, the only difference is that the client
    284284Note that the return value of ''ipc_data_read_finalize()'' is, maybe unjustly, ignored.
    286 === Sharing memory via IPC  === #IpcShareMem
     286== Sharing memory via IPC  == #IpcShareMem
    288288In HelenOS, tasks can share memory only via IPC as the kernel does not provide dedicated system calls for memory sharing. Instead, the tasks negotiate much like in the case of [#IpcDataCopy passing large data]. The negotiation has three phases and is very similar to the previous case:
    294294The semantics of the client and server also remains the same. Note that the direction of sharing is significant as well as it is significant during data copying.
    296 ==== Sharing address space area out ====
     296=== Sharing address space area out ===
    298298When sharing an address space area to other tasks, the client is the sender and the server is the recipient. The client offers one of its address space areas to the server for sharing.