3 ms·

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

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.

amluto 10y ago
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.
aseipp 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      TIL, thanks a lot