Ask HN: Why is no one talking about kernel assisted IPC bus?

Posted by unmdplyr on Sunday February 23, 2020 @10:28PM
from the ask-hn dept.

I've been looking at kd-bus and its later evolution bus1. Seems like both projects are stalled. Why are kernel developers not supportive of a proper messaging system through kernel itself? Or rather what is stopping them from accepting patches to it?

bus1 -> https://bus1.org/

Can someone help me understand?

( 2 comments | 5 points | on HN )

Re:Ask HN: Why is no one talking about kernel assisted IPC bus? by tlb on Sunday February 23, 2020 @10:41PM (#22401457)

Help me understand why Bus1 is a good idea? I'm not an expert, but it seems to me like D-bus accomplishes similar goals without any new mechanisms in the kernel.

[ Parent | on HN ]

Re:Ask HN: Why is no one talking about kernel assisted IPC bus? by unmdplyr on Sunday February 23, 2020 @10:47PM (#22401483)

Having bus functionality enabled in kernel is beneficial for several reasons. It strips out lots of unnecessary bells and whistles and just hold some skeleton for send/receive/advertise. Most POSIX IPCs don't have an advertisement mechanism that enables discovery without some external persuasion.

D-Bus does this but has often been criticised for being overtly complex. OpenWRT came with a simpler solution, but then quickly defined a data protocol which suffers severely in I/O - it needs JSON for everything.

BUS1 doesn't specify a protocol for actual data itself so I can send/recv C struct which my process groups know about it.

Also, leaving bus logic in kernel would mean I can write a minimalistic library wrapping the syscalls for my specialised use, yet keep the applications readily portable should plans change.

[ Parent | on HN ]