Assorted spelling fixes

Signed-off-by: Daniel Mack <daniel@zonque.org>

diff --git a/connection.c b/connection.c
index ac0599c3d941d451558847c32f5cf7f47ce31e2a..c1d561b72a3f98eb756c0a5bb3c9c95e369d6520 100644 (file)
--- a/connection.c
+++ b/connection.c
@@ -384,7 +384,7 @@ int kdbus_conn_entry_insert(struct kdbus_conn *conn_src,
        /*
         * Remember the the reply associated with this queue entry, so we can
         * move the reply entry's connection when a connection moves from an
-        * activator to an implementor.
+        * activator to an implementer.
         */
        entry->reply = kdbus_reply_ref(reply);
 
@@ -615,7 +615,7 @@ int kdbus_cmd_msg_send(struct kdbus_conn *conn_src,
        if (kmsg->res && kmsg->res->dst_name) {
                /*
                 * Lock the destination name so it will not get dropped or
-                * moved between activator/implementor while we try to queue a
+                * moved between activator/implementer while we try to queue a
                 * message. We also rely on this to read-lock the entire
                 * registry so kdbus_meta_add_current() will have a consistent
                 * view of all acquired names on both connections.
@@ -1093,7 +1093,7 @@ void kdbus_conn_release(struct kdbus_conn *conn)
  *                     name, 0 means no filtering.
  *
  * Move all messages from one connection to another. This is used when
- * an implementor connection is taking over/giving back a well-known name
+ * an implementer connection is taking over/giving back a well-known name
  * from/to an activator connection.
  *
  * Return: 0 on success, negative errno on failure.

diff --git a/kdbus.txt b/kdbus.txt
index e5171e21b3d1f65aefdf15d0613d92dd73f5650f..a0f70629e24ae9c752344657a05555597b3131db 100644 (file)
--- a/kdbus.txt
+++ b/kdbus.txt
@@ -189,7 +189,7 @@ compatible.
 
 In 'return_flags', the kernel can return results of the command, in addition
 to the actual return value. This is mostly to inform userspace about non-fatal
-conditions that occured during the execution of the command.
+conditions that occurred during the execution of the command.
 
 
 4. Items
@@ -206,7 +206,7 @@ type. In other cases, they can be of arbitrary length (for instance, a string).
 Items are also used for information stored in a connection's pool, such as
 received messages, name lists or requested connection or bus owner information.
 
-Whenever tems are used as part of the kdbus kernel API, they are embedded in
+Whenever items are used as part of the kdbus kernel API, they are embedded in
 structs that have an overall size of their own, so there can be multiple items
 per ioctl.
 
@@ -233,9 +233,9 @@ the kdbusfs. If you mount kdbusfs multiple times, each will have its own kdbus
 domain internally. Operations performed on one domain do not affect any
 other domain.
 
-The full kdbusfs hierarchy, any subdirectory, or file can be bind-mounted to an
-external mount point and will remain fully functional. The kdbus domain and any
-linked resources stay available until the original mount and all subsequent
+The full kdbusfs hierarchy, any sub-directory, or file can be bind-mounted to
+an external mount point and will remain fully functional. The kdbus domain and
+any linked resources stay available until the original mount and all subsequent
 bind-mounts have been unmounted.
 
 During creation, domains pin the user-namespace of the creator and use
@@ -574,7 +574,7 @@ The offset in the pool has to be freed with the KDBUS_CMD_FREE ioctl.
 ------------------------------------------
 
 An activator connection is a placeholder for a well-known name. Messages sent
-to such a connection can be used by userspace to start an implementor
+to such a connection can be used by userspace to start an implementer
 connection, which will then get all the messages from the activator copied
 over. An activator connection cannot be used to send any message.
 
@@ -814,7 +814,7 @@ struct kdbus_cmd_send {
     KDBUS_CMD_SEND.
 
   __u64 return_flags;
-    Kernel-provided flags, returning non-fatal errors that occured during
+    Kernel-provided flags, returning non-fatal errors that occurred during
     send. Currently unused.
 
   __u64 msg_address;
@@ -864,7 +864,7 @@ struct kdbus_msg {
 
     KDBUS_MSG_NO_AUTO_START
       By default, when a message is sent to an activator connection, the
-      activator notified and will start an implementor. This flag inhibits
+      activator notified and will start an implementer. This flag inhibits
       that behavior. With this bit set, and the remote being an activator,
       -EADDRNOTAVAIL is returned from the ioctl.
 
@@ -1040,7 +1040,7 @@ struct kdbus_cmd_recv {
     Valid flags for this command, returned by the kernel upon each call.
 
   __u64 return_flags;
-    Kernel-provided flags, returning non-fatal errors that occured during
+    Kernel-provided flags, returning non-fatal errors that occurred during
     send. Currently unused.
 
   __s64 priority;
@@ -1180,7 +1180,7 @@ struct kdbus_cmd_name {
 --------------------
 
 A connection may release a name explicitly with the KDBUS_CMD_NAME_RELEASE
-ioctl. If the connection was an implementor of an activatable name, its
+ioctl. If the connection was an implementer of an activatable name, its
 pending messages are moved back to the activator. If there are any connections
 queued up as waiters for the name, the oldest one of them will become the new
 owner. The same happens implicitly for all names once a connection terminates.
@@ -1275,14 +1275,14 @@ struct kdbus_name_info {
       currently waiting for it to become available.
 
     KDBUS_NAME_ACTIVATOR (list)
-      An activator connection owns a name as a placeholder for an implementor,
+      An activator connection owns a name as a placeholder for an implementer,
       which is started on demand as soon as the first message arrives. There's
       some more information on this topic below. In contrast to
       KDBUS_NAME_REPLACE_EXISTING, when a name is taken over from an activator
       connection, all the messages that have been queued in the activator
       connection will be moved over to the new owner. The activator connection
       will still be tracked for the name and will take control again if the
-      implementor connection terminates.
+      implementer connection terminates.
       This flag can not be used when acquiring a name, but is implicitly set
       through KDBUS_CMD_HELLO with KDBUS_HELLO_ACTIVATOR set in
       kdbus_cmd_hello.conn_flags.
@@ -1611,7 +1611,7 @@ and are translated back and forth on the ioctl level accordingly.
 11.2 Wildcard names
 -------------------
 
-Policy holder connections may upload names that contain the wildcard suffix
+Policy holder connections may upload names that contain the wild card suffix
 (".*"). That way, a policy can be uploaded that is effective for every
 well-known name that extends the provided name by exactly one more level.
 

diff --git a/names.c b/names.c
index 414b260db8004fd457931bf640f0d76602424794..95d435f336d8b9f2cc59d38932a638ba2f4b2b7b 100644 (file)
--- a/names.c
+++ b/names.c
@@ -335,7 +335,7 @@ void kdbus_name_remove_by_conn(struct kdbus_name_registry *reg,
  * with NULL as name. In this case, it's a no-op as nothing was locked.
  *
  * The *_lock() + *_unlock() logic is only required for callers that need to
- * protect their code against concurrent activator/implementor name changes.
+ * protect their code against concurrent activator/implementer name changes.
  * Multiple readers can lock names concurrently. However, you may not change
  * name-ownership while holding a name-lock.
  *