Wikipedia

User:ScotXW/kdbus

< User:ScotXW
kdbus
Original author(s)Lennart Poettering, Kay Sievers, Greg Kroah-Hartman, Daniel Mack, Tejun Heo, et al.
Written inC
Typeinter-process communication
LicenseGNU Lesser General Public License
Websitecode.google.com/p/d-bus/source/browse/kdbus.txt
kdbus is implemented as a character device driver.[1][2] All communication between processes take place over special character device nodes in /dev/kdbus (cf. devfs).
Oversimplified: IPC (inter-process communication) hooks a lot into the process scheduler.

kdbus is a character device inside of the Linux kernel to do inter-process communication (IPC). kdbus was design to mostly re-implement D-Bus.

The hurdles edit

To quote: https://www.youtube.com/watch?v=t0jgZKV4N_A "Well, airplane carriers carry air planes…"

  • It seems to be that some kernel maintainers rather want some kGenericIPC instead of only kDBUS.
  • AF_BUS is said to have been "killed" ultimately by David Miller, the kernel maintainer of /net because he disagreed with …
  • Android's Binder:
  • iOS initial release June 29, 2007
  • Android initial release September 23, 2008
  • can do marshalling.

What is D-Bus again? edit

D-Bus or DBus is a specification for inter-process communication (IPC) (and remote procedure call (RPC)) in user-space.

  • D-Bus is a specification, multiple implementations do exists: libdbus, as a reference implementation by freedesktop.org, GDBus, QtDBus, sd-bus, dbus-java, and maybe more
  • like a file is a file-system thing, a process is a kernel-thing. Process = instance of a running program. Only the kernel can pass messages between processes! => D-Bus works on top of the existing IPC primitives in the (Linux) kernel.
  • D-Bus cannot avoid context switches just like that. But I guess, that maybe a programmer using D-Bus can write his stuff in a way, that avoids some context switches compared to when using kernel IPC directly. A process cannot even access a file on the hard disk without a context switch. To be precise, any process needs to ask the kernel to open a file, by issuing a system call = context switch.
  • D-Bus replaced GNOME's CORBA and KDE's DCOP
  • I (User:ScotXW) am guessing here: The idea behind D-Bus has been to provide some easy-to-use way for IPC as compared to the IPC primitives in the kernel.
  • Also, D-Bus works as an abstraction layer, meaning it works on top of Linux, BSD, Windows, OS X, etc!
  • D-Bus has been developed completely in user-space, hard to say, whether during its inception or during its development, the developers meant for D-Bus to one day have an implementation inside of some kernel
    • and attempt to integrate D-Bus into the Linux kernel was kdbus; it failed to be accepted into Linux kernel mainline

mechanism that allows communication between multiple computer programs (that is, processes) concurrently running on the same machine.[3][4] D-Bus was developed as part of the freedesktop.org project, initiated by Havoc Pennington from Red Hat to standardize services provided by Linux desktop environments such as GNOME and KDE.[5][6]

The freedesktop.org project also developed a free and open-source software library called of the specification. This library is often confused with the D-Bus itself. Other implementations of the D-Bus client library also exist, such as (GNOME),[7] QtDBus (Qt/KDE),[8] dbus-java[9] and sd-bus (part of systemd).[10]

What about the existing IPC primitives in the Linux kernel? edit

Sadly File:Oversimplified Structure of the Linux kernel.svg doesn't explain how IPC is implemented inside of the Linux kernel! Looking into [[The Linux Programming Interface] by Michael Kerrisk there is a lot of information about IPC facilities, e.g.

  • Chapter 2.10 "Interprocess Communication and Synchronization":

»A running Linux system consists of numerous processes, many of which operate independently of each other.

Some processes, however, cooperate to achieve their intended purposes, and these processes need methods of communicating with one another and synchronizing their actions.

One way for processes to communicate is by reading and writing information in disk files. However, for many applications, this is too slow and inflexible.

Therefore, Linux, like all modern UNIX implementations, provides a rich set of mechanisms for interprocess communication (IPC), including the following:

  • signals, which are used to indicate that an event has occurred;
  • pipes (familiar to shell users as the | operator) and FIFOs, which can be used to transfer data between processes;
  • sockets, which can be used to transfer data from one process to another, either on the same host computer or on different hosts connected by a network;
  • file locking, which allows a process to lock regions of a file in order to prevent other processes from reading or updating the file contents;
  • message queues, which are used to exchange messages (packets of data) between processes;
  • semaphores, which are used to synchronize the actions of processes;
  • shared memory, which allows two or more processes to share a piece of memory.

When one process changes the contents of the shared memory, all of the other processes can immediately see the changes. The wide variety of IPC mechanisms on UNIX systems, with sometimes overlapping functionality, is in part due to their evolution under different variants of the UNIX system and the requirements of various standards. For example, FIFOs and UNIX domain sockets essentially perform the same function of allowing unrelated processes on the same system to exchange data. Both exist in modern UNIX systems because FIFOs came from System V, while sockets came from BSD.«

The procfs is mounted and represents much of that…

Processes that need to communicate with one another are e.g. dconf, a back-end to GSettings, and everything that needs to access settings data. The settings data is of course stored in some file (plain text or some database file format) like Windows Registry stores its stuff in a 20MiB file. But somehow there is a dconf-daemon (processes that run in the back-ground have been called "daemons" for aeons. But they could alternatively also be called "services". Microsoft has done this, and it seams Red Hat and freedesktop.org also calls daemons now services. There are system daemons/services and session daemons/services.) and the communication with this dconf-daemon takes place over the IPC as defined by the D-Bus specification.

I guess the rationale behind the dconf-daemon is the same as behind the OpenWrt's netifd: track the configuration, in case it changes, make sure that these changes take effect immediately without the user needing to do anything more.

Why does the communication with dconf-daemon take place over D-Bus? I guess, D-Bus offers far more convenient ways for applications developers. GVfs contains a collection of daemons which communicate with each other and the GIO module over D-Bus.

As far as some end-user application like e.g. Inkscape or GIMP retrieves settings data from dconf-daemon, they (probably) use D-Bus.


D-Bus in the kernel edit

The kdbus is the low-level, native kernel D-Bus transport and actively developing now. Tizen developers are trying to replace socket based D-Bus with kdbus based D-Bus on Tizen 3.0 and its products, facing many challenges such as compatibility, security, performance, and others. In this presentation, we will share our experience, the current state, the plans, and the benchmark result. We look forward to replacing socket based D-Bus with kdbus based D-Bus for Linux devices, providing better performance transparently.

Most more modern OS designs than Unix started out with a high-level IPC from the beginning, and then built the rest of the OS on top of it. Linux/Unix began with only the most basic low-level IPC primitives in place (Pipes and stream sockets). Building on those over time various higher-level IPC systems were built, but only very few stood the test of time or became universal. On current Linux systems the best established high-level IPC layer is D-Bus. It implements a reliable message passing scheme, with access control, multicasting, filtering, introspection and supports a flexible object model.

D-Bus is a powerful design. However, being mostly a userspace solution its latency and throughput are not ideal. A full transaction consisting of method call and method reply requires 10 (!) copy operations for the messages passed. It is only useful for transfer of control messages, and not capable of streaming larger amounts of data.

In this talk I'd like to discuss the "kdbus" IPC system, a kernel implementation of the D-Bus logic and its userspace side. "kdbus" takes the concepts of classic D-Bus but makes them more universally useful, reducing latency and roundtrips, and increasing bandwidth, even covering streaming usecases. (For comparison, with kdbus, a full transaction takes only 2 copy operations, even supporting zero-copy for large messages). I'll discuss the lessons we learnt from Android's binder, Solaris' doors IPC system, and Mach's port scheme. We'll discuss, how we implemented a reliable (though probabilistic) multicasting scheme, and the tricks we used in userspace to make transparent zero-copy work, without compromising on security, and providing compatibility with classic D-Bus.

kdbus will soon show up in your favourite distribution as part of the systemd package, please attend if you want to know more about the ideas behind it.

kdbus also came with memfd, a new system call[11] Memfd is a mechanism similar to Android's ashmem that allows zero-copy message passing. Memfd effectively comes down to just a chunk of memory with a FD (file descriptor) attached that can be passed to mmap(). The memfd_create() function returns a raw shmem file and there's optional support for sealing. memfd was mainlined into Linux kernel 3.17.

https://dvdhrm.wordpress.com/tag/memfd/

  • D-Bus is powerful IPC:

Method Call Transactions, Signals, Properties, OO, Broadcasting, Discovery, Introspection, Policy, Activation, Synchronization, Type-safe Marshalling, Security, Monitoring, exposes APIs/not streams, Passing of Credentials, File Descriptor Passing, Language agnostic, Network transparency, no trust required, High-level error concept. . .

  • D-Bus has limitations

Suitable only for control, not payload It’s inefficient (10 copies, 4 complete validations, 4 context switches per duplex method call transaction) Credentials one can send/recv are limited No implicit timestamping Not available in early boot, initrd, late boot Hookup with security frameworks happens in userspace Activatable bus services are independent from other system services Codebase is a bit too baroque, XML, . . . No race-free exit-on-idle bus activated services

  • D-Bus is fantastic, solves real problems

Right approach: good concepts, generic, comprehensive, covers all areas Established, it’s the single most used local, high-level IPC system on Linux, bindings for most languages Used in init system (regardless if systemd or Upstart), the desktops, embedded, . . .

  • kdbus

Suitable for large data (GiB!), zero-copy, optionally reusable It’s efficient (2 or fewer copies, 2 validations, 2 context switches per duplex methd call transaction) Credentials sent along are comprehensive (uid, pid, gid, selinux label, pid starttime, tid, comm, tid comm, argv, exe, cgroup, caps, audit, . . . ) Implicit timestamping Always available, from earliest boot to latest shutdown Open for LSMs to hook into from the kernel side Activation is identical to activation of other services Userspace is much simpler, no XML, . . . Priority queues, . . . Race-free exit-on-idle for bus activated services

memfd edit

Probably should start by summarizing the advantages of memfd over existing interfaces & mechanisms

  • For kdbus, this is the zero-copy message passing (even better for when for when you need to replay a message)
  • For those just wanting to use shared memory in userspace, the underlying file can never be truncated if you seal it against shrinking, so your code never has to muck with exception handling -- this is a pretty big thing for my project.

File sealing edit

Other edit

  • Systemd 202 Starts supporting kdbus

kdbus is a solution for processes to talk to each other that is

  • fast (zero-copy if at all possible)
  • secure
  • behaves mostly like D-Bus – including its introspective and data marshalling features
  • doesn't require a daemon process which manages all of the above

kdbus is a way for processes to talk to each other that is

  1. fast (zero-copy if at all possible)
  2. secure
  3. behaves mostly like dbus – including its introspective and data marshalling features
  4. doesn't require a daemon process which manages all of the above
  5. it should have enough features to eventually supersede Android's binder and ashmem (and pmem) drivers.

Please either tell us how to achieve that with a multicast AF_UNIX and some (OK … a lot) of libdbus_mcast-ish scaffolding around it, or kindly shut up.

Differences between kdbus and Binder edit

...

link dump edit

  • Which is why we have HTTP, and no other way for applications to manipulate TCP/IP sockets, because that would be reinventing the wheel.
  • Once upon a time Linus would frown on these sorts of single-use interfaces. He tended to prefer focusing on making other primitives more performant so that you could compose more complex interfaces in userspace. And for the kernel that's an excellent rule of thumb.
  • Remember the HTTP server wars? Microsoft had a blazing fast HTTP server in-kernel. So somebody coded one up in the Linux kernel, to one up Microsoft. But then somebody with infinitely more sense tweaked some kernel APIs and wrote an HTTP server in user-space that bested both the in-kernel servers.

AF_BUS edit

References edit

  1. ^ "The unveiling of kdbus". LWN.net. 2014-01-13.
  2. ^ "Documentation/kdbus.txt (from the initial patch set)". LWN.net. 2014-11-04.
  3. ^ Cite error: The named reference intro dbus was invoked but never defined (see the help page).
  4. ^ Cite error: The named reference Cocagne 2012 was invoked but never defined (see the help page).
  5. ^ Cite error: The named reference intro dbus q1 was invoked but never defined (see the help page).
  6. ^ Cite error: The named reference Palmieri 2005 was invoked but never defined (see the help page).
  7. ^ Cite error: The named reference gdbus was invoked but never defined (see the help page).
  8. ^ Cite error: The named reference qtdbus was invoked but never defined (see the help page).
  9. ^ Cite error: The named reference dbus-java was invoked but never defined (see the help page).
  10. ^ Cite error: The named reference Poettering 2015 was invoked but never defined (see the help page).
  11. ^ https://github.com/gregkh/kdbus/blob/master/memfd.c
  12. ^ "FOSDEM 2014: Anatomy of kdbus". 2014-02-01. Retrieved 2014-02-17.
  13. ^ "ALS: Linux interprocess communication and kdbus". lwn.net. 2014-02-01. Retrieved 2014-02-17.

External links edit

German language edit


Retrieved from "https://en.wikipedia.org/w/index.php?title=User:ScotXW/kdbus&oldid=947277119"