
Bus1: a new Linux interprocess communication proposal - broodbucket
https://lwn.net/SubscriberLink/697191/d5803573a8c5b84c/
======
qwertyuiop924
No. Nonononononononono. We were ALMOST FREE! Just get these high-level
abstractions out of my effing kernel. They don't belong there. Linus said as
much himself. The only reason kdbus, this thing's predecessor, got so much as
a glance is that Linus trusts Greg KH. A trust I would now consider somewhat
misplaced. This is yet another piece of crap that was tacked on by systemd
nonsense. It's non-portable, and they want us to use it upstack.

Have these people lost their effing minds? Do they think we don't care about
compatability? Just because Lennart said "screw POSIX" doesn't mean you should
do it.

~~~
IshKebab
I agree. I can't see any real reason for this to be in the kernel. Is it
faster? Does it need access to memory in some way you can't do in userspace?
The only practical reason I can think is if it is in the kernel you can 100%
rely on it being present and available. Userspace processes can be killed.

So perhaps the real solution is to provide some kind of mechanism for
userspace processes that act like kernel drivers, in that they are definitely
running all the time, but actually run in userspace.

~~~
lathiat
The two main reasons I know/care about (there may be more) are that it can be
much faster (zero copy, reduced context switches) and also guarantee the
message isn't changed while reading (by sealing the originating buffer).

The last is something you need kernel help to enforce.

~~~
saynsedit
There's no case for this usually marginal speed benefit.

Most programs are dealing with vastly slower bottlenecks. Like network or disk
latency. IPC latency is so far down the list of priorities in terms of things
to optimize.

Not to mention that regular user-kernel-user buffer copying is plenty fast
now, especially since the buffers will likely be cache-resident. Zero-copy is
mostly hype without performance numbers to back it up. Don't need this complex
message sealing mechanism.

------
CaliforniaKarl
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](https://lwn.net/op/FAQ.lwn#subs)

Subscription prices are here:
[https://lwn.net/subscribe/Info](https://lwn.net/subscribe/Info)

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

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

~~~
ndesaulniers
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!_

~~~
ahoka
> You can't pass file descriptors over sockets.

You can:

[http://man7.org/tlpi/code/online/dist/sockets/scm_rights_sen...](http://man7.org/tlpi/code/online/dist/sockets/scm_rights_send.c.html)

~~~
justin66
Nice. I've used that book and recommend it to people but I've never seen that
before. I don't know how I would find it, either, since it doesn't appear to
be indexed anywhere.

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

~~~
aseipp
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/](https://lwn.net/Articles/504970/)

~~~
digi_owl
Another alternative i have seen aired it to use TIPC. A protocol that has been
in the kernel since 2.6.

[http://tipc.sourceforge.net/tipc_linux.shtml](http://tipc.sourceforge.net/tipc_linux.shtml)

~~~
ahoka
TIPC is very good protocol, I was working on very robust systems built on it.

Just a quick list of features, from Wikipedia:

    
    
        Location transparency of services in a network
        Auto-discovery mechanism
        Reliable transport
        Standard socket interface support
        Connectionless, connection-oriented and multicast messaging
        Subscription to network events

~~~
nzjrs
TIL, thanks a lot

------
f2f
"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 :)

~~~
Annatar
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_!!!

~~~
chme
> Flux.

And while all that is constantly changing, its still possible to compile very
old user space software and run it in on a current kernel.

~~~
majewsky
Well yeah, most of the libc API is older than Linux.

~~~
ekidd
The Linux libc API changed a couple of times in the 1990s (a.out → ELF, libc5
→ libc6, etc), but the Linux _kernel_ ABI (what libc uses to talk to the
kernel) has been stable since practically the beginning. Linus detests
breaking anything that talks to the kernel and considers it massively
unprofessional, to the point that even a terrible API will be set in stone if
anything uses it.

------
digi_owl
And the cascade keeps cascading...

~~~
chme
Its just so much easier to add new functionality to the kernel than to remove
old ones.

~~~
digi_owl
Because then they don't have to deal with Torvalds "we don't break userspace"
stance. Especially as the devs involved seems to hate maintaining API
compatibility...

