sd-bus: drop kdbus-related docs (#5533)

Makefile.am

@@ -677,8 +677,6 @@ dist_doc_DATA = \
 	LICENSE.LGPL2.1 \
 	LICENSE.GPL2 \
 	DISTRO_PORTING \
-	src/libsystemd/sd-bus/PORTING-DBUS1 \
-	src/libsystemd/sd-bus/DIFFERENCES \
 	src/libsystemd/sd-bus/GVARIANT-SERIALIZATION
 
 EXTRA_DIST += \
@@ -3411,7 +3409,6 @@ noinst_LTLIBRARIES += \
 
 EXTRA_DIST += \
 	src/libsystemd/libsystemd.pc.in \
-	src/libsystemd/sd-bus/DIFFERENCES \
 	src/libsystemd/sd-bus/GVARIANT-SERIALIZATION
 
 libsystemd_la_SOURCES =

src/libsystemd/sd-bus/DIFFERENCES

@@ -1,25 +0,0 @@
-Known differences between dbus1 and kdbus:
-
-- NameAcquired/NameLost is gone entirely on kdbus backends if
-  libsystemd is used. It is still added in by systemd-bus-proxyd
-  for old dbus1 clients, and it is available if libsystemd is used
-  against the classic dbus1 daemon. If you want to write compatible
-  code with libsystem-bus you need to explicitly subscribe to
-  NameOwnerChanged signals and just ignore NameAcquired/NameLost
-
-- Applications have to deal with spurious signals they didn't expect,
-  due to the probabilistic bloom filters. They need to handle this
-  anyway, given that any client can send anything to arbitrary clients
-  anyway, even in dbus1, so not much changes.
-
-- clients of the system bus when kdbus is used must roll their own
-  security. Only legacy dbus1 clients get the old XML policy enforced,
-  which is implemented by systemd-bus-proxyd.
-
-- Serial numbers of synthesized messages are always (uint32_t) -1.
-
-- NameOwnerChanged is a synthetic message, generated locally and not
-  by the driver. On dbus1 only the Disconnected message was
-  synthesized like this.
-
-- There's no standard per-session bus anymore. Only a per-user bus.

src/libsystemd/sd-bus/GVARIANT-SERIALIZATION

@@ -73,10 +73,9 @@ the reply_cookie/reply_serial additional header field has been
 increased from 32bit to 64bit, too!
 
 The header field identifiers have been extended from 8bit to
-64bit. This has been done to simplify things (as kdbus otherwise uses
-exclusively 64bit types, unless there is a strong reason not to), and
-has no effect on the serialization size, as due to alignment for each
-8bit header field identifier 56 bits of padding had to be added.
+64bit. This has been done to simplify things, and has no effect
+on the serialization size, as due to alignment for each 8bit
+header field identifier 56 bits of padding had to be added.
 
 Note that the header size changed, due to these changes. However,
 consider that on dbus1 the beginning of the fields array contains the
@@ -94,16 +93,12 @@ array, the size of the header on dbus1 and dbus2 stays identical, at
 
 And that's already it.
 
-Note: to simplify parsing, valid kdbus/dbus2 messages must include the
-entire fixed header and additional header fields in a single non-memfd
-message part. Also, the signature string of the body variant all the
-way to the end of the message must be in a single non-memfd part
-too. The parts for this extended header and footer can be the same
-one, and can also continue any amount of additional body bytes.
-
-Note: on kdbus only native endian messages marshalled in gvariant may
-      be sent. If a client receives a message in non-native endianness
-      or in dbus1 marshalling it shall ignore the message.
+Note: To simplify parsing, valid dbus2 messages must include the entire
+      fixed header and additional header fields in a single non-memfd
+      message part. Also, the signature string of the body variant all the
+      way to the end of the message must be in a single non-memfd part
+      too. The parts for this extended header and footer can be the same
+      one, and can also continue any amount of additional body bytes.
 
 Note: The GVariant "MAYBE" type is not supported, so that messages can
       be fully converted forth and back between dbus1 and gvariant