After you have done that: here's the basic principle how kdbus works:
-You connect to a bus by opening its bus node in /dev/kdbus/. All
+You connect to a bus by opening its bus node in /sys/fs/kdbus/. All
buses have a device node there, it starts with a numeric UID of the
owner of the bus, followed by a dash and a string identifying the
-bus. The system bus is thus called /dev/kdbus/0-system, and for user
-buses the device node is /dev/kdbus/1000-user (if 1000 is your user
+bus. The system bus is thus called /sys/fs/kdbus/0-system, and for user
+buses the device node is /sys/fs/kdbus/1000-user (if 1000 is your user
id).
(Before we proceed, please always keep a copy of libsystemd next
The kernel will return in the "id" field your unique id. This is a
simple numeric value. For compatibility with classic dbus1 simply
-format this as string and prefix ":0.".
+format this as string and prefix ":1.".
The kernel will also return the bloom filter size and bloom filter
hash function number used for the signal broadcast bloom filter (see
contained in the payload, as well is immediately before framing of a
Gvariant, as well after as any padding bytes if there are any. The
padding bytes must be wholly contained in the preceding
- PAYLOAD_VEC/PAYLOAD_MEMFD item. You may not split up simple types
- nor arrays of trivial types. The latter is necessary to allow APIs
- to return direct pointers to linear chunks of fixed size trivial
- arrays. Examples: The simple types "u", "s", "t" have to be in the
- same payload item. The array of simple types "ay", "ai" have to be
+ PAYLOAD_VEC/PAYLOAD_MEMFD item. You may not split up basic types
+ nor arrays of fixed types. The latter is necessary to allow APIs
+ to return direct pointers to linear arrays of numeric
+ values. Examples: The basic types "u", "s", "t" have to be in the
+ same payload item. The array of fixed types "ay", "ai" have to be
fully in contained in the same payload item. For an array "as" or
"a(si)" the only restriction however is to keep each string
individually in an uninterrupted item, to keep the framing of each
i.e. KDBUS_ITEM_NAME_ADD, KDBUS_ITEM_NAME_REMOVE,
KDBUS_ITEM_NAME_CHANGE, KDBUS_ITEM_ID_ADD, KDBUS_ITEM_ID_REMOVE and
fill them out. Note however, that you have some wildcards in this
-case, for example the .id field of KDBUS_ITEM_ADD/KDBUS_ITEM_REMOVE
+case, for example the .id field of KDBUS_ITEM_ID_ADD/KDBUS_ITEM_ID_REMOVE
structures may be set to 0 to match against any id addition/removal.
Note that dbus match strings do no map 1:1 to these ioctl() calls. In
MEMFDS
-The "memfd" concept is used for zero-copy data transfers (see
-above). memfds are file descriptors to memory chunks of arbitrary
-sizes. If you have a memfd you can mmap() it to get access to the data
-it contains or write to it. They are comparable to file descriptors to
-unlinked files on a tmpfs, or to anonymous memory that one may refer
-to with an fd. They have one particular property: they can be
-"sealed". A memfd that is "sealed" is protected from alteration. Only
-memfds that are currently not mapped and to which a single fd refers
-may be sealed (they may also be unsealed in that case).
-
-The concept of "sealing" makes memfds useful for using them as
-transport for kdbus messages: only when the receiver knows that the
-message it has received cannot change while looking at, it can safely
-parse it without having to copy it to a safe memory area. memfds can also
-be reused in multiple messages. A sender may send the same memfd to
-multiple peers, and since it is sealed, it can be sure that the receiver
-will not be able to modify it. "Sealing" hence provides both sides of
-a transaction with the guarantee that the data stays constant and is
-reusable.
-
-memfds are a generic concept that can be used outside of the immediate
-kdbus usecase. You can send them across AF_UNIX sockets too, sealed or
-unsealed. In kdbus themselves, they can be used to send zero-copy
-payloads, but may also be sent as normal fds.
-
-memfds are allocated with the KDBUS_CMD_MEMFD_NEW ioctl. After allocation,
-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 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
-the memfd open, and if the memfd is currently unmapped.
-
-If memfds are shared, keep in mind that the file pointer used by
-write/read/seek is shared too, only pread/pwrite are safe to use
-in that case.
-
memfds may be sent across kdbus via KDBUS_ITEM_PAYLOAD_MEMFD items
attached to messages. If this is done, the data included in the memfd
is considered part of the payload stream of a message, and are treated
Client libraries should use the following connection string when
connecting to the system bus:
- kernel:path=/dev/kdbus/0-system/bus;unix:path=/var/run/dbus/system_bus_socket
+ kernel:path=/sys/fs/kdbus/0-system/bus;unix:path=/var/run/dbus/system_bus_socket
This will ensure that kdbus is preferred over the legacy AF_UNIX
socket, but compatibility is kept. For the user bus use:
- kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus
+ kernel:path=/sys/fs/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus
With $UID replaced by the callers numer user ID, and $XDG_RUNTIME_DIR
following the XDG basedir spec.
~ianmdlvl / elogind.git / blobdiff