<citerefentry>
<refentrytitle>kdbus.message</refentrytitle>
<manvolnum>7</manvolnum>
- </citerefentry>).
+ </citerefentry>
+ ).
Each bus is independent, and operations on the bus will not have any
effect on other buses. A bus is a management entity that controls the
addresses of its connections, their policies and message transactions
<refentrytitle>kdbus.fs</refentrytitle>
<manvolnum>7</manvolnum>
</citerefentry>
- a bus is presented as a directory. No operations can be performed on
+ , a bus is presented as a directory. No operations can be performed on
the bus itself; instead you need to perform the operations on an endpoint
associated with the bus. Endpoints are accessible as files underneath the
bus directory. A default endpoint called <constant>bus</constant> is
<citerefentry>
<refentrytitle>kdbus.item</refentrytitle>
<manvolnum>7</manvolnum>
- </citerefentry>)
- are expected for <constant>KDBUS_CMD_BUS_MAKE</constant>.
+ </citerefentry>
+ ) are expected for <constant>KDBUS_CMD_BUS_MAKE</constant>.
</para>
<variablelist>
<varlistentry>
<citerefentry>
<refentrytitle>kdbus.match</refentrytitle>
<manvolnum>7</manvolnum>
- </citerefentry>).
+ </citerefentry>
+ ).
</para>
<para>
Messages synthesized and sent directly by the kernel will carry the
</varlistentry>
<varlistentry>
- <term><varname>attach_flags</varname></term>
+ <term><varname>flags</varname></term>
<listitem><para>
Specifies which metadata items should be attached to the answer. See
<citerefentry>
<refentrytitle>kdbus.message</refentrytitle>
<manvolnum>7</manvolnum>
- </citerefentry>.
+ </citerefentry>
</para></listitem>
</varlistentry>
<term><varname>items</varname></term>
<listitem>
<para>
- The following item types are supported.
+ Items to describe the connection details to be updated. The
+ following item types are supported.
</para>
<variablelist>
<varlistentry>
<para>
To update an existing endpoint, the
<constant>KDBUS_CMD_ENDPOINT_UPDATE</constant> command is used on the file
- descriptor that was used to create the endpoint, using
+ descriptor that was used to create the update, using
<constant>KDBUS_CMD_ENDPOINT_MAKE</constant>. The only relevant detail of
the endpoint that can be updated is the policy. When the command is
employed, the policy of the endpoint is <emphasis>replaced</emphasis>
<term><constant>KDBUS_ITEM_NEGOTIATE</constant></term>
<listitem><para>
With this item is attached to any ioctl, programs can
- <emphasis>probe</emphasis> the kernel for known item types.
+ <emphasis>probe</emphasis> the kernel for known item items.
The item carries an array of <type>uint64_t</type> values in
<varname>item.data64</varname>, each set to an item type to
probe. The kernel will reset each member of this array that is
When received as item attached to a message, the array will
contain the numbers of the installed file descriptors, or
<constant>-1</constant> in case an error occurred.
+ file descriptor.
In either case, the number of entries in the array is derived from
the item's total size. See
<citerefentry>
a remote peer is a member of, stored as array of
<type>uint32_t</type> values in <varname>item.data32</varname>.
The array length can be determined by looking at the item's total
- size, subtracting the size of the header and dividing the
+ size, subtracting the size of the header and and dividing the
remainder by <constant>sizeof(uint32_t)</constant>.
</para></listitem>
</varlistentry>
This item is sent as attachment to a
<emphasis>kernel notification</emphasis>. It informs the receiver
that an expected reply to a message was not received in time.
- The remote peer ID and the message cookie are stored in the message
+ The remote peer ID and the message cookie is stored in the message
header. See
<citerefentry>
<refentrytitle>kdbus.message</refentrytitle>
<emphasis>kernel notification</emphasis>. It informs the receiver
that a remote connection a reply is expected from was disconnected
before that reply was sent. The remote peer ID and the message
- cookie are stored in the message header. See
+ cookie is stored in the message header. See
<citerefentry>
<refentrytitle>kdbus.message</refentrytitle>
<manvolnum>7</manvolnum>
possibly along with some other rules to further limit the match.
The kernel will match the signal message's bloom filter against the
- connection's bloom mask (simply by &-ing it), and will decide whether
+ connections bloom mask (simply by &-ing it), and will decide whether
the message should be delivered to a connection.
</para>
<para>
<title>Generations</title>
<para>
- Uploaded matches may contain multiple masks, which have to be as large
- as the bloom filter size defined by the bus. Each block of a mask is
- called a <emphasis>generation</emphasis>, starting at index 0.
+ Uploaded matches may contain multiple masks, which have are as large as
+ the bloom size defined by the bus. Each block of a mask is called a
+ <emphasis>generation</emphasis>, starting at index 0.
At match time, when a signal is about to be delivered, a bloom mask
generation is passed, which denotes which of the bloom masks the filter
<title>Adding a match</title>
<para>
To add a match, the <constant>KDBUS_CMD_MATCH_ADD</constant> ioctl is
- used, which takes a <type>struct kdbus_cmd_match</type> as an argument
- described below.
+ used, which takes a struct of the struct described below.
Note that each of the items attached to this command will internally
create one match <emphasis>rule</emphasis>, and the collection of them,
An item that carries the bloom filter mask to match against
in its data field. The payload size must match the bloom
filter size that was specified when the bus was created.
- See the "Bloom filters" section above for more information on
- bloom filters.
+ See the section below for more information on bloom filters.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
- The message referenced by the <varname>msg_address</varname> above has
+ The fields in this struct are described below.
+ The message referenced the <varname>msg_address</varname> above has
the following layout.
</para>
<listitem>
<para>
Actual data records containing the payload. See section
- "Message payload".
+ "Passing of Payload Data".
</para>
</listitem>
</varlistentry>
<listitem><para>
Whenever a message with <constant>KDBUS_MSG_SIGNAL</constant> is sent
but cannot be queued on a peer (e.g., as it contains FDs but the peer
- does not support FDs, or there is no space left in the peer's pool)
+ does not support FDs, or there is no space left in the peer's pool..)
the 'dropped_msgs' counter of the peer is incremented. On the next
RECV ioctl, the 'dropped_msgs' field is copied into the ioctl struct
and cleared on the peer. If it was non-zero, the
<varlistentry>
<term><constant>E2BIG</constant></term>
<listitem><para>
- Too many items.
+ Too many items
</para></listitem>
</varlistentry>
<varlistentry>
<term><constant>EAGAIN</constant></term>
<listitem><para>
- No message found in the queue.
+ No message found in the queue
</para></listitem>
</varlistentry>
</variablelist>
<listitem>
<para>
When a message is sent (<constant>KDBUS_CMD_SEND</constant>),
- information about the sending task and the sending connection is
+ information about the sending task and the sending connection are
collected. This metadata will be attached to the message when it
arrives in the receiver's pool. If the connection sending the
message installed faked credentials (see
To let the kernel know which metadata information to attach as items
to the aforementioned commands, it uses a bitmask. In those, the
following <emphasis>attach flags</emphasis> are currently supported.
- Both the <varname>attach_flags_recv</varname> and
+ Both the the <varname>attach_flags_recv</varname> and
<varname>attach_flags_send</varname> fields of
<type>struct kdbus_cmd_hello</type>, as well as the payload of the
<constant>KDBUS_ITEM_ATTACH_FLAGS_SEND</constant> and
<para>
These ioctls, along with the structs they transport, are explained in
- detail in the other documents linked to in the "See Also" section below.
+ detail in the other documents linked to in the 'see also' section below.
</para>
</refsect1>
projects / platform / kernel / linux-exynos.git / commitdiff