Bus1: a new Linux interprocess communication proposal

Re:Bus1: a new Linux interprocess communication proposal by stormbrew on Thursday August 18, 2016 @01:19AM (#12310552)

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.

[ Parent | on HN ]

Re:Bus1: a new Linux interprocess communication proposal by aseipp on Thursday August 18, 2016 @01:47AM (#12310630)

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/

[ Parent | on HN ]

Re:Bus1: a new Linux interprocess communication proposal by digi_owl on Thursday August 18, 2016 @04:01AM (#12311007)

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

[ Parent | on HN ]

Re:Bus1: a new Linux interprocess communication proposal by ahoka on Thursday August 18, 2016 @04:55AM (#12311196)

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

[ Parent | on HN ]

Re:Bus1: a new Linux interprocess communication proposal by nzjrs on Thursday August 18, 2016 @07:28AM (#12311634)

TIL, thanks a lot

[ Parent | on HN ]

Re:Bus1: a new Linux interprocess communication proposal by amluto on Thursday August 18, 2016 @01:31AM (#12310587)

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.

[ Parent | on HN ]