Bus1 – Kernel Message Bus

Re:Bus1 – Kernel Message Bus by zarvox on Wednesday October 26, 2016 @10:13PM (#12802428)

My impression is that bus1 appears to have taken the (copious) feedback from the kdbus debacle and actually applied it and looked at other platforms' IPC to build a novel IPC system for Linux worth using. There's a talk [1] about the design of bus1, and comparison against IPC on other platforms where IPC is saner, and how the capability model is the right design for IPC - composable, understandable, and secure-by-default. It strikes me that the bus1 devs arrived at their design after doing the things you suggested! :)

Is there something I'm missing? What might an ideal IPC API look like to you?

[1] - https://www.youtube.com/watch?v=6zN0b6BfgLY

[ Parent | on HN ]

Re:Bus1 – Kernel Message Bus by pmontra on Thursday October 27, 2016 @03:27AM (#12803433)

> What might an ideal IPC API look like to you?

Erlang's internal IPC is doing it pretty well since before there was a Linux kernel. I don't know if that approach can be ported into the kernel and how complex they are behind the scenes, but spawn / send / receive are apparently simple concepts.

In Erlang: http://erlang.org/doc/getting_started/conc_prog.html#id68696

In Elixir: http://elixir-lang.org/getting-started/processes.html

[ Parent | on HN ]

Re:Bus1 – Kernel Message Bus by swhipple on Thursday October 27, 2016 @05:53AM (#12803892)

Authentication, authorization, and resource quotas for agents are not really addressed in the Erlang model, but would be expected for IPC on a Unix-like system.

[ Parent | on HN ]

Re:Bus1 – Kernel Message Bus by pmontra on Thursday October 27, 2016 @06:11AM (#12803942)

Do we really want to put all of that into the kernel and not implementing it in userland? I get the feeling that it's too much application dependent, not enough general principles.

Maybe I just don't understand the problem they are out to solve.

[ Parent | on HN ]

Re:Bus1 – Kernel Message Bus by swhipple on Thursday October 27, 2016 @06:31AM (#12803986)

The reason for a bus-style IPC implemented in the kernel is the same that sendfile(2) exists. I doubt anyone thinks it's the pinnacle of great design, but reduced copies and context switching for real application workload: sometimes the more 'proper' design is sacrificed for practicality.

[ Parent | on HN ]

Re:Bus1 – Kernel Message Bus by ktRolster on Wednesday October 26, 2016 @10:44PM (#12802561)

What might an ideal IPC API look like to you?

I can't answer that because I don't have a PhD related to IPC, and I haven't done the necessary research to fully understand the field. I have looked at how some other systems are doing it, but I know that is not a strong enough knowledge-base to build a good IPC system.

I do have enough understanding to know that when I look at a good IPC api, I will look at it and say, "wow, that's really nice."

[ Parent | on HN ]

Re:Bus1 – Kernel Message Bus by jononor on Thursday October 27, 2016 @06:12AM (#12803949)

Which IPC apis do you consider really nice? And which not?

[ Parent | on HN ]

Re:Bus1 – Kernel Message Bus by fiddlerwoaroof on Thursday October 27, 2016 @11:46AM (#12806072)

What do you think of zeromq?

[ Parent | on HN ]