I'm not worried. Linus won't accept kdbus until he thinks it's in a
position where it will be stable and easily supported for the foreseeable
future. Watching kdbus get refactored a few times over this past year, I'd
wager a guess that they're going to end up keeping as much of dbus in
userspace as possible, and only add the parts that absolutely must run in
kernel space to the kernel (as kdbus). Thus far, this has been limited to
the memfd API, which is needed for zero-copy memory transfers. They'll
probably also end up adding a specialized kdbusfs (akin to devpts) that
offers namespaced and permissioned access to dbus endpoints, represented as
a hierarchy of character device files.

Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The
reason they're working on kdbus at all is because they have discovered that
it's costly to pipe a lot of data between dbus endpoints, and it's hard to
control capabilities, visibility, and access to them (since there are
usecases where endpoints may not trust each other). Arguably, these
problems can be addressed by using a combination of existing IPC
mechanisms, but the argument that Greg KH and company put forth over and
over again is that there's too much legacy code using dbus at this point
(namely, from the IVI community and desktop communities) that we can't just
tell them to refactor everything. It might be true--I don't know how big
the IVI codebases are, for example. However, I don't really sympathize
with the desktop communities--they built dbus to their specifications from
their experiences with DCOP and Bonobo, and still managed to get it wrong.

My $0.02.
-Jude