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

61–70 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#61

Post by justin66 »

ahoka wrote: post #33
ndesaulniers wrote: post #20

Earlier quoted context omitted.

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…

> You can't pass file descriptors over sockets. You can: http://man7.org/tlpi/code/online/dist/sockets/scm_rights_sen...

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.

Re: Bus1: a new Linux interprocess communication proposal

#62

Post by saynsedit »

lathiat wrote: post #51
IshKebab wrote: post #48

Earlier quoted context omitted.

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…

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.

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.

Re: Bus1: a new Linux interprocess communication proposal

#63

Post by the_why_of_y »

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?

AF_UNIX sockets don't do multi-cast.

AF_INET sockets don't do FD passing or credentials.

There was a patch to add an AF_BUS socket family some years ago that sounded like a pretty general solution but the network maintainer said "over my dead body".

http://lwn.net/Articles/504970/

Re: Bus1: a new Linux interprocess communication proposal

#64

Post by Annatar »

qwertyuiop924 wrote: post #47
Annatar wrote: post #16

Earlier quoted context omitted.

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…

Well, you're feeling nice and smug, as usual. And after vomiting upon seeing this, I don't blame you. OTOH, some of the above you mentioned isn't bad. Linux's "just a kernel" philosophy can be useful, and allows people to experiment with new inits (s6, runit, &c) and new systems that come in handy. And go see Brendan Gregg's talk on Linux tracers. It's not as simple is dtrace, given the tracing war hasn't been won, b…

Well, you're feeling nice and smug, as usual.

Yes I am, because I picked a highly reliable, stable substrate to build my own private infrastructure on.

Re: Bus1: a new Linux interprocess communication proposal

#65

Post by saynsedit »

sjellis wrote: post #53
qwertyuiop924 wrote: post #50

Earlier quoted context omitted.

That's just a daemon. The reason this is in the kernel is that DBus is slow (according to Linus, because it could have been written better by monkeys with typewriters), and Lennart wanted it in the kernel/systemd, and Greg KH agreed, and Linus trusts Greg.

The announcement email from David Herrmann explains that they did consider a user-space implementation, and lists the reasons why they decided that it had to be in-kernel: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...

The reasons are mostly performance reasons. As I said in my other post, IPC latency is way down in the priority list of things to optimize (relatively to network and disk latency).

Unless the application is a HPC parallel computation that is IPC bound, Bus1 has no performance justification. If the main justification for a modern kernel IPC mechanism is performance, I'd much much much more trust a proposal coming out of the HPC community than the desktop experience community.

Re: Bus1: a new Linux interprocess communication proposal

#66

Post by saynsedit »

CJefferson wrote: post #30
dozzie wrote: post #25

Earlier quoted context omitted.

> You can't pass file descriptors over sockets. Good that my code doesn't know this. It would stop working. > The descriptors and authentication part is key, [...] If by "authentication" you mean "checking PID/UID/GID", we already have both in unix sockets.

How do you pass a file descriptor through a socket? They just take bytes? If you mean "I send some bytes that describes the file to open, and keep my processes in sync manually", of course you can do that, but true passing would allow a number of cool things.

http://bfy.tw/7HAG

Re: Bus1: a new Linux interprocess communication proposal

#67

Post by the_why_of_y »

qwertyuiop924 wrote: post #45

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…

Exactly! They should just use the Android Binder IPC that was merged some years ago and was widely heralded as a pinnacle of open development, good design and especially security. (Getting Binder standardized in the next revision of POSIX is surely a mere formality.)

Re: Bus1: a new Linux interprocess communication proposal

#68

Post by qwertyuiop924 »

the_why_of_y wrote: post #67
qwertyuiop924 wrote: post #45

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…

Exactly! They should just use the Android Binder IPC that was merged some years ago and was widely heralded as a pinnacle of open development, good design and especially security. (Getting Binder standardized in the next revision of POSIX is surely a mere formality.)

No, it's not. Binder was designed for Java, and the rest of the Unix family doesn't support it.

Re: Bus1: a new Linux interprocess communication proposal

#69

Post by rwmj »

qwertyuiop924 wrote: post #45

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…

I thought the interesting part of kdbus was the "memory sealing" - you could take a shared memory buffer, write to it, then "seal" it (so no further changes were allowed) and share it with another process. I believe you cannot efficiently do that in userspace. That doesn't seem to be part of this proposal.

Re: Bus1: a new Linux interprocess communication proposal

#70

Post by pjmlp »

saynsedit wrote: post #58
pjmlp wrote: post #31

Earlier quoted context omitted.

> UNIX is a paradox where everybody uses it but most people don't really know how to use it. Specially when the majority nowadays has the idea that GNU/Linux == UNIX and never tried to write an actual portable UNIX application.

Eh? The majority of modern POSIXy software runs on at least Linux, Mac OS X, and FreeBSD. In fact, Mac OS X is the most widely deployed UNIX-like system ever. What you're a claiming to be true probably more applies to Mac OS X than Linux. I honestly haven't seen a recent package that was accidentally not portable in the long-term across the various modern UNIX-like systems because of confusion of Linux for POSIX.

There are more UNIX flavours than those ones.
Post reply on HN