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

31–40 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#31

Post by pjmlp »

chubot wrote: post #13
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…

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

Re: Bus1: a new Linux interprocess communication proposal

#33

Post by ahoka »

ndesaulniers wrote: post #20
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…

> You can't pass file descriptors over sockets.

You can:

http://man7.org/tlpi/code/online/dist/sockets/scm_rights_sen...

Re: Bus1: a new Linux interprocess communication proposal

#34

Post by ahoka »

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.

By passing it as ancillary data: http://linux.die.net/man/3/cmsg

Re: Bus1: a new Linux interprocess communication proposal

#35

Post by jamespo »

Annatar wrote: post #16
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…

ZFS/SMF/zones etc are due to the engineering excellence at Sun though, I'd be interested to know of the innovation/improvements since Oracle slammed the door on OpenSolaris.

Re: Bus1: a new Linux interprocess communication proposal

#36

Post by ahoka »

digi_owl wrote: post #22
aseipp wrote: post #12

Earlier quoted context omitted.

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/

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

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

Re: Bus1: a new Linux interprocess communication proposal

#37

Post by cyphar »

rodgerd wrote: post #4
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?

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

You couldn't send credentials nor file descriptors to other processes without UNIX sockets. I would argue that allowing for that kind of decoupling of permissions and file access is very much in the spirit of the UNIX philosophy. Quite frankly, there are some problems you simply wouldn't be able to solve without them (in runC, the underlying runtime that Docker wraps, we use them quite extensively).

Re: Bus1: a new Linux interprocess communication proposal

#38

Post by digi_owl »

chme wrote: post #26
digi_owl wrote: post #2

And the cascade keeps cascading...

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

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

Re: Bus1: a new Linux interprocess communication proposal

#39

Post by RantyDave »

jamespo wrote: post #35
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…

ZFS/SMF/zones etc are due to the engineering excellence at Sun though, I'd be interested to know of the innovation/improvements since Oracle slammed the door on OpenSolaris.

You can now start a zone that's compatible with 64-bit Linux, or one that runs a "hardware" hypervisor, or mix and match the two. That sort of thing?
Post reply on HN