Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bus1: a new Linux interprocess communication proposal

lwn.net

Post reply on HN
Print view View original

11–20 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#11

Post by amluto »

stormbrew wrote: post #9

Is 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.

It's not a particularly good fit for the socket API. In particular, communication is unidirectional at its most basic and uses something a lot like seL4's "reply capabilities". It's a very nice, if counterintuitive, design, and it can give an asymptotic memory usage reduction, but it means that sendto and recvfrom don't work the usual way.

Re: Bus1: a new Linux interprocess communication proposal

#12

Post by aseipp »

stormbrew wrote: post #9

Is 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.

I believe one of the original proposals in this design space was AF_BUS[1], which was actually in fact a new socket address family. But that design used domain sockets, which were extended to support multicast -- and it was rejected as making an already complex path more complicated, among other reasons.

[1] https://lwn.net/Articles/504970/

Re: Bus1: a new Linux interprocess communication proposal

#13

Post by chubot »

nixos wrote: post #3

Can 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?

I'm very sympathetic to that point of view -- UNIX is a paradox where everybody uses it but most people don't really know how to use it.

But this paper makes a good quantitative case for POSIX not meeting the needs of modern computing: https://news.ycombinator.com/item?id=11652609

A good example is that Linux distros, Android, and OS X all have their own non-POSIX IPC mechanisms. Applications are somehow voting with their feet and not using Unix domain sockets and pipes.

It leaves me scratching my head because I don't think serialization is that hard a problem. But it seems that most people want IPC with structured data. Android is a bit of a special case because it's a single-language OS.

"Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and SQLite [1]."

Re: Bus1: a new Linux interprocess communication proposal

#14

Post by thwarted »

bitwize wrote: post #8
amscanne wrote: post #5

Earlier quoted context omitted.

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.

How's it perform on tmpfs or ramdisk?

Re: Bus1: a new Linux interprocess communication proposal

#15

Post by pjc50 »

Pyxl101 wrote: post #7
nixos wrote: post #3

Can 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 t…

Global message order sounds like the kind of commitment that becomes increasingly expensive in a multi core environment..

Re: Bus1: a new Linux interprocess communication proposal

#16

Post by Annatar »

f2f wrote: post #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 :)

That's the thing about Linux: they have literally not one, but multiple armies of "programmers", and yet even after 20+ years of an absolutely furious development pace, basic things like inter-process communication still do not work desirably. Startup/shutdown? Yep, you know it already, it's still in flux (SMF in illumos has been humming along for a decade now). Filesystems? Flux. Observability? Flux. libc, what libc, that comes from GNU, flux. libstdc++, yeah we just decided to implement a "version 3 of that", flux. Debugging format? You have to rip out your runtime linker in order to get DWARF 2 support (DWARF 2 has been available for 23 years now), so, flux. Virtualization? Wait, which one of the 56 not-quite-right virtualization solutions do I mean, because Linux people are flapping with that and nobody can get it right? Flux.

The illumos kernel has been stable for decades now. Teams of five people here, three people there, four people over there, they roll up their sleeves, look at the issues the customers have had and are actually having now, professional engineers with formal education and insight, and in two years they have a working product which only needs a small fix here or there, and is tenable decades into the future. It goes to show that the number of programmers does not a quality, working product make.

For example: it's 2016, and my Linux filesystems in Vertica suddenly go into read-only mode, nobody knows why yet. In 2016! I cannot believe I just typed that, but it's true.

I've been running ZFS since 2006 both professionally and privately on Solaris and SmartOS at several large companies and I have never seen it go into read-only mode. The team which designed ZFS was only five people, not an army.

Bryan Cantrill summed it up so profoundly when, upon showing SmartOS running Linux applications, he ran /native/bin/dtrace and proclaimed:

I have clean water!!!

Re: Bus1: a new Linux interprocess communication proposal

#17

Post by wahern »

bitwize wrote: post #8
amscanne wrote: post #5

Earlier quoted context omitted.

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.

1) They want better performance over the existing solutions. For better or worse applications are [arguably] abusing the heck out of D-Bus. Using regular files might help with huge messages, but it's a lot of overheard for many small messages.

2) They want the ability to insert a broker that manages permissions among the peers, but have the kernel enforce those permissions on a per message basis so the broker doesn't become a bottleneck. That's not easy to with the filesystem.

I mean, strictly speaking it's theoretically possible using the file system considering that in practice the only real broker would be systemd with a fixed set of policies, so theoretically the traditional Unix model of user, group, and supplementary groups would suffice by assigning users and processes into the proper groups, and binding message files into protected group-readable directories. But for whatever pretense, people want the solution to implement a system of opaque, ephemeral identifiers/capabilities.

It sort of reminds me of SMF, launchd, systemd, and similar changes. For example, I was installing Solaris 11.3 on a VM yesterday and was trying to figure out how to set the hostname. You used to set it by storing the hostname to /etc/nodename. Now it's stored in some opaque tree data structure deep in the bowels of SMF, which you set with some long and impenetrable command-line utility invocation. You can still set /etc/nodename; if no hostname is configured then SMF will initialize the hostname from /etc/nodename and delete the file. It boggles the mind.

Re: Bus1: a new Linux interprocess communication proposal

#18

Post by digi_owl »

nixos wrote: post #3

Can 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?

Because the automotive industry wants to move from QNX to Linux, and wants to use dbus like they used QNX IPC beforehand. Thus we have projects like streaming video over dbus(?!).

https://lwn.net/Articles/551969/

Re: Bus1: a new Linux interprocess communication proposal

#19

Post by voltagex_ »

CaliforniaKarl wrote: post #6

The 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

I second this, just resubscribed. (LWN's financial situation is not as good as it has been in the past)

Re: Bus1: a new Linux interprocess communication proposal

#20

Post by ndesaulniers »

nixos wrote: post #3

Can 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?

In Binder's case, it makes RPC between different languages significantly easier.

You can't pass file descriptors over sockets. You can't do RPC over pipes. Anonymous sockets can only be shared with children. Named sockets require write permission and a filesystem. SysV is prone to resource leaks.

Binder has authentication, shared memory, reference counting, weak references, dead object notifications.

The descriptors and authentication part is key, as it allows Android's trusted system_server to open a device or socket for an untrusted process such as an App if it has user permissions. The receiver of a binder request can check the requester's PID/GID and with confidence from the kernel.

Most importantly, I don't think it's healthy to think of POSIX as being done. Some experimentation and discovery of better APIs and better systems should be encouraged.

gah, I'm driving myself crazy; I swear I saw somewhere a diagram of the Taxonomy of Unix IPC Mechanisms, with most of them crossed out and replaced simply with binder, please help me find it!

Post reply on HN