summaryrefslogtreecommitdiff
path: root/src/libsystemd-bus/PORTING-DBUS1
diff options
context:
space:
mode:
Diffstat (limited to 'src/libsystemd-bus/PORTING-DBUS1')
-rw-r--r--src/libsystemd-bus/PORTING-DBUS18
1 files changed, 4 insertions, 4 deletions
diff --git a/src/libsystemd-bus/PORTING-DBUS1 b/src/libsystemd-bus/PORTING-DBUS1
index b8a6ff77d1..f52d24ba4f 100644
--- a/src/libsystemd-bus/PORTING-DBUS1
+++ b/src/libsystemd-bus/PORTING-DBUS1
@@ -69,7 +69,7 @@ format this as string and prefix ":0.".
The kernel will also return the bloom filter size used for the signal
broadcast bloom filter (see below).
-The kernel will also return the bus ID of the bus in an 128bit field.
+The kernel will also return the bus ID of the bus in a 128bit field.
The pool size field specifies the size of the memory mapped buffer.
After the calling the hello ioctl, you should memory map the kdbus
@@ -367,7 +367,7 @@ simply memory map them and write to them. To set their size, use
KDBUS_CMD_MEMFD_SIZE_SET. Note that memfds will be increased in size
automatically if you touch previously unallocated pages. However, the
size will only be increased in multiples of the page size in that
-case. Thus, in almost all cases, an explicitl KDBUS_CMD_MEMFD_SIZE_SET
+case. Thus, in almost all cases, an explicit KDBUS_CMD_MEMFD_SIZE_SET
is necessary, since it allows setting memfd sizes in finer
granularity. To seal a memfd use the KDBUS_CMD_MEMFD_SEAL_SET ioctl
call. It will only succeed if the caller has the only fd reference to
@@ -404,7 +404,7 @@ MESSAGES FROM THE KERNEL
A couple of messages previously generated by the dbus1 bus driver are
now generated by the kernel. Since the kernel does not understand the
payload marshaling, they are generated by the kernel in a different
-format. This is indicated with a the "payload type" field of the
+format. This is indicated with the "payload type" field of the
messages set to 0. Library implementations should take these messages
and synthesize traditional driver messages for them on reception.
@@ -473,7 +473,7 @@ metadata than they asked for themselves, to simplify implementation of
broadcasting in the kernel. The receiver should not rely on this data
to be around though, even though it will be correct if it happens to
be attached. In order to avoid programming errors in applications, we
-recommend though not to pass this data on to clients that did not
+recommend though not passing this data on to clients that did not
explicitly ask for it.
Credentials may also be queried for a well-known or unique name. Use