D-bus,kdbus and Binder

Http://blog.sina.com.cn/s/blog_4af327e10101irie.html

Materials from: The unveiling of Kdbus and Kdbus Details. The content of many links in the latter article is also valuable.

advantages and disadvantages of D-bus

Linux does not have a good IPC mechanism. Windows, MacOS, and Android have a "binder" subsystem. Linux has sockets, FIFO, shared memory and other mechanisms, which are not very good for the application layer. Kdbus attempts to create a mechanism that is similar to other systems for Linux.

D-bus is the closest approach to this standard on Linux. Pros: Provides a good transaction handling mechanism (which supports sending messages and waits for a response) and sends signals to other subsystems, knowing which subsystems are in operation and what services are available on D-bus. D-bus also provides support for security policies, initial use is to start the service, type-safe organization of data structures, passing of credentials and file descriptors on the bus. In addition, many programming languages have d-bus binding interfaces, as well as network transport transparency.

Limitations: D-bus is suitable for control tasks, but is not suitable for transferring large amounts of data. For example, D-bus can inform the Audio service program to change the volume (D-bus famous example, hehe), but it is not suitable for transmitting audio data. Because D-bus is implemented in user space, it is inefficient: One call-return message requires 10 message copies, 4 message authentication, and 4 context switches. In addition, the credential delivery capability is limited, the message does not have a timestamp, boot D-bus is not available (at this point D-bus not started), and the security framework (such as SELinux) connection in the user space, activating the service may have a race condition and so on. D-bus is also too complex to implement and relies heavily on XML.

moving into the kernel

Kdbus is the implementation of D-bus in the kernel. Large chunks of data can be transferred for GB-level message flow. 0 Copies of message delivery can be done, in the worst case, a message and its reply process is no more than 2 copy operations, 2 validations, 2 context switches. All credential information (user ID, process id,selinux tags, cgroup information, permissions, and so on) is delivered with each message, and all messages have a timestamp. Kdbus is ready to use, without waiting for the D-bus daemon to start, the Linux security module can be linked directly to avoid race conditions and the API will be simplified.

Kdbus is used as a character device in the kernel; the process to connect to the open device, and then call Mmap () to map a message delivery area to its own address space. The message is assembled in this area and handed to the kernel for transmission; The kernel simply copies the message from one process-mapped region to the zone of another process. Messages can carry a time limit on the receipt of replies ("Method call Window"). There is a name record table similar to D-bus.

The Kdbus implements 0 copies of message delivery through the MEMFD mechanism. MEMFD is a memory area with a file descriptor, a bit similar to a memory-mapped temporary file (which is actually very different). A MEMFD can be "sealed"-the process that owns it cannot change its contents anymore. To pass a message, the process first constructs the message in the Memfd area, seals it, and then passes it to the Kdbus transport. The kernel can map the corresponding memory pages to the address space of the receiving process, thus avoiding copying the data, depending on the size of the message. Message comparison hours (approximately 512KB or less) the memory mapping overhead is relatively large, when the data is copied directly.

The signal broadcasting mechanism uses the Bloom filter to select the recipient. This change has improved the efficiency of broadcasting mechanisms.

The current plan is to merge the code into the backbone of the kernel in 2014. However, the previous two attempts to move the D-bus function into the kernel failed, this time there is no guarantee of success (looks like a big, redhat already in the SYSTEMD to use the Kdbus).

Kdbus and Binder differences--CPU Center and Ram Center

Binder provides synchronous invocation (CPU) of threads from one task to another in Android. In this process, the calling thread hangs until the answering thread returns, and no Message Queuing is required. RAM is only used to share data among different callers. The key to the Binder library in Android is that the calling process gives its own CPU time slice to the answering process. This is like a mutex system call. There is a direct link between the process of communicating with each other. There is an upper limit to the number of processes that can use binder simultaneously in the system, and most systems are estimated at about 16.

D-bus is asynchronous, it queues messages in the queue (RAM), and the receiver takes messages from the queue. The task of the CPU is to carry data in RAM. This is similar to the network communication protocol. is a "no connection" communication mode between processes. The upper limit is approximately 8Mb per connection, and a message is usually at 200-800 bytes.

Binders are created for micro-kernel class devices. Limited functionality, lack of flexibility, but low overhead and fast speed. Binder guarantees that the CPU time slices are passed from the calling process to the calling process's thread, and then returned to the calling process when the work is completed. There is little need for process scheduling, which is ideal for devices with low RAM and CPU configuration.

D-bus is a message model that creates-stores-forwards, builds replies, and then creates-stores-forwards. More complex than bind, also more flexible, universal, network transparent, easy to manage, and can easily manage untrusted peer-to-peer communication (don't let binder face this situation, otherwise ...) D-bus can handle large chunks of data, and in the Kdbus implementation, you can transfer GB-level data to each connection on the bus. From the CPU point of view, D-bus is not biander efficient, but more versatile.

A binder-like function can be implemented in the D-bus. It is not good to say whether D-bus will replace binder later.

D-bus,kdbus and Binder