From: Djalal Harouni Date: Wed, 28 Jan 2015 22:43:31 +0000 (+0100) Subject: doc: KDBUS_MSG_PAYLOAD_{VEC|MEMFD} => KDBUS_ITEM_PAYLOAD_{VEC|MEMDF} X-Git-Tag: upstream/0.20150129.081441utc~1 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=df1c1bf855795b34e39d7ae236fcce93c3e6ed72;p=platform%2Fcore%2Fsystem%2Fkdbus-bus.git doc: KDBUS_MSG_PAYLOAD_{VEC|MEMFD} => KDBUS_ITEM_PAYLOAD_{VEC|MEMDF} KDBUS_MSG_PAYLOAD_{VEC|MEMFD} were renamed to KDBUS_ITEM_PAYLOAD_{VEC|MEMDF} Signed-off-by: Djalal Harouni --- diff --git a/doc/kdbus.message.xml b/doc/kdbus.message.xml index 289a9d7..7a9f9f1 100644 --- a/doc/kdbus.message.xml +++ b/doc/kdbus.message.xml @@ -71,7 +71,7 @@ struct kdbus_cmd_send { non-blocking. However, as there are many use cases that need to wait for a remote peer to answer a method call, there's a way to send a message and wait for a reply in a synchronous fashion. This is what - the KDBUS_MSG_SYNC_REPLY controls. The KDBUS_CMD_SEND ioctl will block + the KDBUS_SEND_SYNC_REPLY controls. The KDBUS_CMD_SEND ioctl will block until the reply has arrived, the timeout limit is reached, in case the remote connection was shut down, or if interrupted by a signal before any reply; see signal(7). @@ -447,7 +447,7 @@ struct kdbus_msg { - KDBUS_MSG_PAYLOAD_VEC + KDBUS_ITEM_PAYLOAD_VEC Messages are directly copied by the sending process into the receiver's pool. @@ -458,7 +458,7 @@ struct kdbus_msg { - KDBUS_MSG_PAYLOAD_MEMFD + KDBUS_ITEM_PAYLOAD_MEMFD Messages can reference memfd files which contain the data.