If tuned to its utmost- is not only necessarily inferior to e.g. In addition I'll argue that as currently specified, the kdbus interface- even Kdbus seeks to provide: naming, broadcast, unidirectional signaling,īidirectional "method calls", and a policy mechanism. Throughput and latency and that the latter are directly applicable toĬonstructing a more convenient user-space IPC broker that implements what Userspace ABI specified in the kdbus 4.1-rc1 version (of April this year) willĪlways be necessarily slower than existing IPC primitives in terms of both 10k SLOC of IPC broker and policy engine into kernel space.įurthermore, it's my well-ruminated opinion that implementations of the Them solely in user-space without significant performance demerit, and without Interfaces are fine to the point that other mechanisms may be derived from I'll contend that the reason for this vacuum is that the existing kernel IPC > that is already upstream - but does not. > and extending Android's existing kernel accelerated IPC subsystem (Binder) The political reason is that SystemD could be using > IPC ABI at the moment that distros can rely on as a 'golden standard'. > So there exists a technical vacuum: the kernel does not have any good, modern Near-equivalent to the state of the art in terms of performance. You do IPC when function calls are zomgfast already?)- but rather, that theĮxisting ones either are good enough at this time or can be reworked to become Inapplicable to a monolithic kernel for reasons of ABI (and, well, why would a different microkernel IPC mechanism- those are by and large However, the suggested replacement in kdbus replicates the worst of all Hoariest of vendor unixes suggests it's not supposed to be even close. State-of-the-art even at the level of interface indeed its presence in the It's also my understanding that no-one in their right mind would call SysV IPC Hot data across the address space boundary. Via mmap(), signals, mappings that appear shared across fork(), and whateverĮlse provides either kernel-mediated multi-client buffer access or someĬombination of shared memory and synchronization that lets userspace exchange Things in the kernel also, such as unix domain sockets, pipes, shared memory SysV message queues, and POSIX message queues. It's my understanding that linux/ipc/* contains only SysV IPC, i.e. > for existing usecases, but no-one was maintaining and enhancing it with the > last 10 years the linux/ipc/* code has been dormant: it works and was kept good >- I've been closely monitoring Linux kernel changes for over 20 years, and for the Quite the ball of mud even if the only thing under the scope is its interface,Īnd that if i held off until properly ready i'd risk kdbus having already been i started down that road only to realize that kdbus is apologies for length.Īs my "proper" review on this topic is still under construction, i'll try (andįail) to be brief here. Kernel IPC in particular, so i'll weigh in uninvited. I've got quite a bit of knowledge on message-passing mechanisms in general, and [delurk apparently kdbus is not receiving the architectural review it should. 16:51 ` David Herrmann 0 siblings, 1 reply 69+ messages in threadįrom: Kalle A. Re: kdbus: to merge or not to merge? LKML Archive on help / color / mirror / Atom feed * Re: kdbus: to merge or not to merge? 0:03 Kalle A.
0 Comments
Leave a Reply. |