lcall
| Number | 0x15 |
|---|---|
| Signature | (port, len) -> {0, recv_len} |
| Group | messaging |
| Since | 1.0 |
| Blocking | true |
Long-message request/response: send from the lmsg buffer and block for a reply written back into it. A reply capability is minted into the receiver’s table, and its slot index is what arrives in the receiver’s r0 (or res->source under waitany).
The long message buffer is inside the TLS ( on ARMv7: TPIDRURO -> tdata_t -> lmsg_buf) and is LMSG_BUF_SIZE bytes large. That’s how lreply gets addressed. You can use functions in channel.h to abstract the lmsg buffer operations.
Pitfalls
The buffer is one buffer, so the reply lands on top of the request. The caller must save the data they had sent if they wish to keep it, and after the call is complete, the data must be copied out of the lmsg buffer.
Arguments
| Register | Name | Description |
|---|---|---|
r0 | port | Handle of the server port |
r1 | len | Request byte count in the lmsg buffer |
Returns
On success, r0 = 0 and r1 = the reply length in the lmsg buffer.
Errors
| Code | Condition |
|---|---|
ERR_OVERFLOW | Length of message exceeds the lmsg buffer size. |
ERR_BADHANDLE | No such port exists for the given handle. |
ERR_BADTYPE | The type of handle is not a port. |
ERR_DEAD | Recipient has died before the reply could be sent. |
ERR_NOMEM | Reply capability allocation failed, or the receiver's handle table is full. |