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

21–30 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#21

Post by grandinj »

pjc50 wrote: post #15
Pyxl101 wrote: post #7

Earlier quoted context omitted.

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

hence the use of some nifty optimised clocking algorithms:

https://github.com/bus1/bus1/wiki/Message-ordering

Re: Bus1: a new Linux interprocess communication proposal

#22

Post by digi_owl »

aseipp wrote: post #12
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/

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

Re: Bus1: a new Linux interprocess communication proposal

#23

Post by cnvogel »

digi_owl wrote: post #18
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/

    > Large automotive companies have built huge systems on top of QNX
    > messages, creating large libraries used by their applications.
    > They would like to be able to use those libraries 
    > on Linux, but often don't know that there is
    > a way to get the QNX message API for Linux. It is called SIMPL
    > and it works well.
(from the LWN article)

Re: Bus1: a new Linux interprocess communication proposal

#24

Post by chme »

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…

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

Re: Bus1: a new Linux interprocess communication proposal

#25

Post by dozzie »

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.

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.

Re: Bus1: a new Linux interprocess communication proposal

#27

Post by majewsky »

chme wrote: post #24
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…

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

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

Re: Bus1: a new Linux interprocess communication proposal

#28

Post by vidarh »

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…

It will always be in flux because it reflects what Illumos doesn't have: A userbase as diverse and large as Linux, of which a large proportion have competing needs and wishes and the ability to change it at will. This is not just about license either, but about the availability of people who understand the kernel.

I'm sure we could have something cleaner with a single, coherent team. But we also would have something that'd be useful to far fewer people.

Linux wins not by being best at everything. It has plenty of ugly warts. It wins by being accessible ranging from e.g. my ability to just take a job 20 years ago to port it to a custom x86 board with no bios or hard drive, because everything I needed was easily available, to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development, to the ability for people to just write "yet another filesystem" and have actual real people try to use it and give feedback and contribute code.

The most important part of the success and value of Linux is that community. Without the community, it'd have little to offer over any number of other kernels that are better in some areas, worse in others.

But with it, it stands head and shoulder above all kinds of technically very impressive solutions because I can do things with and to Linux that I can't do, or can't do cheaply enough or in short enough time, with alternatives (and yes, that can be because of lack of knowledge of alternatives, but that too is part of the community/network effect).

Don't underestimate the importance of people.

> The team which designed ZFS was only five people, not an army.

And that's great. But the whole ZFS saga is also an illustration of how licensing early on can hamper adoption (KDE vs Gnome is another good illustration of how important license is; and how lasting the effect can be even after the licensing issues are sorted)

Re: Bus1: a new Linux interprocess communication proposal

#30

Post by CJefferson »

dozzie wrote: post #25
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. 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.

Post reply on HN