Bus1: a new Linux interprocess communication proposal
1–10 of 139 posts
Re: Bus1: a new Linux interprocess communication proposal
#2And the cascade keeps cascading...
Re: Bus1: a new Linux interprocess communication proposal
#3Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
Re: Bus1: a new Linux interprocess communication proposal
#4Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
> what's wrong with the classical UNIX sockets
Well, for starters they're a bolt-on that doesn't fit with the actual classic Unix philosophy.
Re: Bus1: a new Linux interprocess communication proposal
#5Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
AFAIK, there's no good way to "broadcast" messages without bouncing through a user space co-ordinator. The current primitives just don't match this kind of need. Presumably, this inefficiency could be a bottleneck for some cases and eliminating the extra step might help, plus a kernel implementation could be simpler (no extra daemons, etc.)
Re: Bus1: a new Linux interprocess communication proposal
#6The link used here is a subscriber link, which means an existing subscriber decided to make this post available to the entire HN community during its non-free period.
If you find this content useful, and you aren't already a LWN subscriber, you should consider becoming one!
More info is here: https://lwn.net/op/FAQ.lwn#subs
Subscription prices are here: https://lwn.net/subscribe/Info
Re: Bus1: a new Linux interprocess communication proposal
#7Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
The design goals of bus1 are described here: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...
Some call-outs for you:
> * efficiently support n-to-n communication. * be well-suited for both unicast and multicast messages. * guarantee a global message order. * avoid any in-kernel buffering and rather transfer data directly from a sender into the receiver's mappable queue (single-copy).
The downside of the alternatives that you mention is that they're not available as kernel features in Linux. Bus1 is inspired by that previous work and aims to make a new attempt at inclusion in the kernel, which they believe is required to provide the features they're targeting:
> A user-space implementation of bus1 (or even any bus-based IPC) was considered, but was found to have several seemingly unavoidable issues.
> o To guarantee reliable, global message ordering including multicasts, as well as to provide reliable capabilities, a bus-broker is required. In other words, the current linux syscall API is not sufficient to implement the design as described above in an efficient way without a dedicated, trusted, privileged process that manages the bus and routes messages between the peers. (...)
Re: Bus1: a new Linux interprocess communication proposal
#8Can someone please explain what's wrong with the classical UNIX sockets and pipes that they need to invent and (re)invent dbus, bonobo, now bus1?
AFAIK, there's no good way to "broadcast" messages without bouncing through a user space co-ordinator. The current primitives just don't match this kind of need. Presumably, this inefficiency could be a bottleneck for some cases and eliminating the extra step might help, plus a kernel implementation could be simpler (no extra daemons, etc.)
I wrote a proof of concept that does multicast using the file system and inotify. A bit hacky and there are drawbacks, but it works.
Re: Bus1: a new Linux interprocess communication proposal
#9Is there a reason this couldn't be done as a new socket type (initialized by socket()) instead of either a dedicated new system call and/or the device node they're doing now? I'm not sure it'd be important to do that instead, I'm just curious if there's an obvious rationale I'm missing.
Re: Bus1: a new Linux interprocess communication proposal
#10"To create a new node, an application performs any of the various ioctl() operations that accept a handle, passing the special reserved handle number of "3".
what a bunch of jokers :)