Lines Matching defs:message
96 alias \> call \> enum \> in \> interface \> message \\
157 \item A simple message specification, using either the \texttt{message},
159 single unidirectional message with typed arguments,
160 and described in Section~\ref{sec:lang:message}.
170 one message in every interface.
231 \subsection{Simple message}\label{sec:lang:message}
233 A simple message specification takes the form:
237 message|call|response \synit{name} \verb+(+\synit{argdecl}, \ldots \verb+)+;
240 The three identifiers \texttt{message}, \texttt{call}, and \texttt{response}
262 For example, the following defines a message named ``dummy'' with three
267 message dummy(int32 arg, string s, uint8 buf[buflen]);
279 syntax as for a simple message, but are prefixed with either \texttt{in} or
292 to the following message specifications:
295 message testrpc_call(string s);
296 message testrpc_response(errval reterr);
324 --msgbuf-header Create a header file for message buffers
325 --msgbuf-stub Create a stub file for message buffers
353 Most Flounder backends generate message stubs for specific interconnect
368 message basic(uint32 arg);
369 message str(uint32 arg, string s);
370 message caps(uint32 arg, cap cap1, cap cap2);
371 message buf(uint8 buf[buflen]);
480 /* returns true iff a message could currently be accepted by the binding */
483 /* register an event for when a message is likely to be able to be sent */
496 /* Incoming message handlers (filled in by user) */
521 When a message arrives, the binding implementation calls the \emph{receive
523 pointers. This table has an entry for each message type, with arguments
524 corresponding to those of the message, as shown below:
551 if a message arrives on a binding and the handler function for that message
554 Any message arguments passed by reference become the property of the user, and
568 A message may be sent on the binding by calling the appropriate transmit
583 \emph{continuation} closure (described below), followed by the message payload.
584 If it returns success, the message has been successfully enqueued for
588 which will be executed after the given message has been successfully sent.
594 All binding implementations can buffer exactly one outgoing message. If another
597 binding is not currently able to accept another message. In this case, the user
602 Any message arguments passed by reference (strings, arrays, and capabilities)
603 are borrowed by the binding, and must remain live for as long as the message
622 an outgoing message for transmission. Note this does not indicate the message
634 given waitset when the binding is able to accept another outgoing message
664 receiver on every message send.
681 prints a message and terminates the current dispatcher.
704 These events are typically raised by message channels in response to activity,
705 such as the ability to receive a message on a specific channel. In the
725 no longer used exclusively for message channels.} represented internally by the
727 into the state of a real message channel or other event mechanism.
731 message, as distinct from the ability to receive a message) are supported by
837 message transport mechanisms. Chapter~\ref{cha:icds} describes the specifics
843 \item A mechanism to \emph{send} a message on a channel
855 that is always present is local message passing (LMP), which provides
876 \lstinline+alloc_iref_request+ message to its local monitor, passing an opaque
879 \lstinline+alloc_iref_reply+ message.
899 capability to a shared frame, which will be used for message transfer.
902 using a \lstinline+bind_ump_request+ message (NB: mislabelled
906 \lstinline+bind_ump_service_request+ message. It also provides the
913 \lstinline+bind_ump_reply_monitor+ message (labelled
931 code, can directly deliver a capability along with untyped message payload.
933 from message payload through the monitors.
938 This is necessary, because it must send a message to its local monitor, and
941 non-capability payload of the message as usual.
943 \item Upon receipt of the first message payload, the receiver sends back an
949 acknowledgement has been seen, a \lstinline+cap_send_request+ message
960 \lstinline+cap_send_request+ message on the inter-monitor channel.
964 \lstinline+cap_receive_request+ message.
970 \item When the last capability and message payload are received, the binding
971 object delivers the message to the user as usual.
977 \section{LMP: local (intra-core) message passing}
980 IDC between dispatchers on the same core uses LMP (local message passing). LMP
1001 When a message is sent, the sender invokes the remote endpoint cap with the
1002 message to send. This causes the kernel to copy the message into the associated
1005 then finds the endpoint with a message in it and invokes the trigger on the
1007 rest of the message out of the buffer and invoking appropriate user-defined
1023 \textbf{Passing capabilities - LMP:} When a capability is sent in a message, then
1034 \section{UMP: user-level message passing with coherent shared memory}
1037 IDC between dispatchers on different cores uses UMP (user-level message passing)
1069 read-only for the receiver) each message has a sequence id. When replying to the
1082 be sent in two phases. The non-cap message is sent as normal. The capability
1089 \section{RCK: message passing on the SCC}
1092 \section{BMP: Beehive message passing}