OpenCores
URL https://opencores.org/ocsvn/c0or1k/c0or1k/trunk

Subversion Repositories c0or1k

[/] [c0or1k/] [trunk/] [docs/] [man/] [man7/] [l4_ipc.7] - Blame information for rev 2

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 2 drasko
.TH L4_IPC 7 2009-11-02 "Codezero" "Codezero Programmer's Manual"
2
.SH NAME
3
.nf
4
.BR "l4_ipc" " - Inter-process communication"
5
 
6
.SH SYNOPSIS
7
.nf
8
.B #include 
9
.B #include 
10
 
11
.BI "int l4_ipc(l4id_t " "to, " "l4id_t " "from, " "unsigned int " "flags" ")"
12
.SH DESCRIPTION
13
.BR l4_ipc()  " call provides the main inter-process communication mechanism on Codezero. Upon an ipc call between two threads, message registers that are stored in one thread's UTCB block are transferred to the other thread's UTCB block, in synchronous fashion. The amount and nature of the data transferred depends on the type of ipc call. See below for details.
14
 
15
The UTCB is a memory block that is private to each thread's address space and it's purpose is to provide thread-local storage to each thread. See
16
.BR "utcb " "(7) "
17
for more details.
18
 
19
.IR "to " " and " "from " "fields  jointly determine whether the ipc is going to be a
20
.B send
21
or a
22
.B receive.
23
.RI "A valid thread id in the " " to " " field, and an"
24
.B L4_NILTHREAD
25
.RB " value in the "
26
.I from
27
.RB "field denotes the ipc is a " "send" ", and when the fields are vice versa, it denotes the ipc is a " "receive" "."
28
 
29
.RI "If both " "from " "and " "to " "fields have valid thread ids, the ipc becomes a joint"
30
.B send
31
and
32
.BR "receive" ","
33
.RB "i.e. a " "send " "operation is followed by a " "receive " "operation during a single call."
34
This particular variant is useful for calling server-like services, where the request would be received, processed, and a result reply would be sent back.
35
 
36
.RB "There is also an " "L4_ANYTHREAD " "parameter that may be used in the"
37
.IR "from " "field. This parameter allows a receiver to receive from any thread in the system. This notion is useful for implementing server-like services, where any sender may be accepted and served on a first-come, first-served basis. It is also worth noting that in such a scenario, the sender must possess the capabilities to call the receiver."
38
.RB "For more information on capabilities, see " "capability" "(7)."
39
 
40
.RI "The " "flags " "field determines what type of ipc is going to be initiated. In Codezero, there are three types of IPC defined as shown below:"
41
.TP
42
.B Short IPC
43
.RB "This is the shortest and simplest form of ipc where only the " "Primary Message Registers " " are transferred. Primary message registers are a handful of registers that are resident on the first few slots of the UTCB. During an ipc, these registers may be optionally mapped to real registers on the cpu as an optimisation, but this notion is transparent of the API. It is worth noting that the number of these registers may be variable depending on the configuration and the platform. See the section " "MESSAGE REGISTERS" " below for a detailed explanation of the possible set of roles each register may take in an ipc."
44
 
45
.TP
46
.B Full IPC
47
A full ipc transfers the complete set of message registers resident on the UTCB of the thread, including the primary MRs. The total number of these registers may be variable depending on the configuration and the platform, although a good estimate would be the total size of the UTCB minus the size of the thread-local fields defined on the UTCB.
48
 
49
.TP
50
.B Extended IPC
51
This is a special type of ipc where the UTCB is not involved at all. It is the most flexible type of ipc provided by Codezero. On an extended ipc,
52
.I any
53
buffer in a thread's address space may be transferred to
54
.I any
55
buffer on another thread's address space. Page faults are also allowed to occur on the buffers, provided that a third party thread not involved in the ipc is ready to handle the faults. An extended ipc also defines a variable size for the transfer, and transfers may be of up to 2 Kilobytes in size. An extended ipc is smp-safe and brings no negative timing burden on system in overall, although the parties involved in the ipc may block for an unpredictable amount of time due to the possibility of page faults.
56
.ti 7
57
 
58
It is recommended that for transfers larger than 2KB in size, shared memory is used.
59
 
60
.SH MESSAGE REGISTERS
61
.TP
62
.RB "On " "short " "and " "full " "ipc, all primary message registers are available for transferring raw data. Particularly, the kernel imposes no restriction on these registers, and has no interference with their contents. However, almost always some of these registers may be used for designated purposes in userspace. Some of them are listed below:"
63
 
64
.ti 16
65
.TP
66
.B MR_TAG
67
The tag register allows the caller to define a label for the ipc. It defines the primary reason for an ipc call.
68
.TP
69
.B MR_SENDER
70
The sender register is only meaningful for a thread that has done a receive on any thread, via the
71
.B L4_ANTHREAD
72
special thread id. Also, this is the only exception where the kernel interferes with the contents of a message register, such that the kernel indicates the thread id of the sender to the caller. This exception must be made, since otherwise a sender could disguise its identity by placing arbitrary values into one of the MRs that the receiver expects to find the sender information.
73
.TP
74
.B MR_RETURN
75
This register is used for sending back a result when handling a joint
76
.B send/receive
77
request. Since it is only relevant on the return phase of an ipc call, it may well be the same register that was designated for the receive phase of a call.
78
 
79
.in 7
80
The above registers may also be called as
81
.B system registers.
82
Note that they are solely defined by the
83
.B libl4
84
library, and their designated labels have no meaning outside of the userspace context. Since they are used by their label on most ipc calls, further registers have been defined to identify a set that lies outside the above set.
85
.RB "These are the system call argument registers, and they are labelled as " "L4SYS_ARG0" ", " " L4SYS_ARG1" ", and " "L4SYS_ARG2 " "respectively."
86
 
87
 
88
.SH L4 USERSPACE LIBRARY
89
 
90
.nf
91
/* Short IPC Calls */
92
.BI "static inline int l4_send(l4id_t " "to" ", unsigned int " "tag" ");"
93
.BI "static inline int l4_receive(l4id_t " "from" ");"
94
.BI "static inline int l4_sendrecv(l4id_t " "to" ", l4id_t " "from" ", unsigned int " "tag" ");"
95
 
96
.nf
97
/* Full IPC Calls */
98
.BI "static inline int l4_send_full(l4id_t " "to" ", unsigned int " "tag" ");"
99
.BI "static inline int l4_receive_full(l4id_t " "from" ");"
100
.BI "static inline int l4_sendrecv_full(l4id_t " "to" ", l4id_t " "from" ", unsigned int " "tag" ");"
101
 
102
.nf
103
/* Extended IPC Calls */
104
.BI "static inline int l4_send_extended(l4id_t " "to" ", unsigned int " "tag" ", unsigned int " "size" ", void " "*buf" ");"
105
.BI "static inline int l4_receive_extended(l4id_t " "from" ", unsigned int " "size" ", void " "*buf" ");"

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.