Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bus1 – Kernel Message Bus

bus1.org

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Bus1 – Kernel Message Bus

#31

Post by swhipple »

pmontra wrote: post #20
zarvox wrote: post #13

Earlier quoted context omitted.

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-def…

> 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/pr…

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.

Re: Bus1 – Kernel Message Bus

#32

Post by mfukar »

solidsnack9000 wrote: post #3

> Also in the case where there can be no causal relationship, we are guaranteed > a global order. In case two events happend concurrently, there can never be > any inconsistency in which occurred before the other. By way of example, > consider two peers sending one message each to two different peers, we are > guaranteed that both the recipient peers receive the two messages in the same > order, even though the order…

With their "synchronize-local-clocks" approach, it doesn't.

They are using Lamport's algorithm to synchronize the clocks. However, Lamport's approach creates a _partial_ ordering, and to make that a _total_ ordering you need some mechanism to break "ties". For instance, the PID, or whatever.

The catch is that the relationship derived from this arbitrary tie-breaking mechanism has nothing to do with causality, and therefore the total order it imposes is only an artifact of the mechanism chosen.

Finding a tie-breaking mechanism that corresponds to the sending events is, in Lamport's own words, "not trivial".

Re: Bus1 – Kernel Message Bus

#34

Post by pmontra »

swhipple wrote: post #31
pmontra wrote: post #20

Earlier quoted context omitted.

> 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/pr…

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.

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.

Re: Bus1 – Kernel Message Bus

#36

Post by jononor »

ktRolster wrote: post #14
zarvox wrote: post #13

Earlier quoted context omitted.

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-def…

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,…

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

Re: Bus1 – Kernel Message Bus

#37

Post by swhipple »

pmontra wrote: post #34
swhipple wrote: post #31

Earlier quoted context omitted.

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.

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.

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.

Re: Bus1 – Kernel Message Bus

#38

Post by Matthias247 »

Although I have brought a lot of high level RPC/IPC systems into production I'm really having a hard time imagining where I could use this.

As far as I understand it gives me a bit more high level features (security, multicast) compared to other IPC primitives (sockets, pipes, ...). However once I'm going to use this my application (or high-level IPC framework) will be locked to Linux and no longer be portable to other platforms. So for any applications that should be at least halfway portable I would prefer something that works on the more common primitives (most likely sockets) and build something more powerful in a cross-plattform way on top ofi it (like HTTP, grpc, Thrift, ...).

A full featured low-level framework makes sense if I have a whole set of applications on top of it which is not intended to be portable and uses it exclusively. Something like the Android/iOS/... platform. But the current ones already have settled on their infrastructure (e.g. on Binder), and even if new ones come up there is a high possibility that they wouldn't like at least something in Bus1 and instead come up with their own solution.

Re: Bus1 – Kernel Message Bus

#40

Post by tomegun »

Asooka wrote: post #27
MBCook wrote: post #15

Earlier quoted context omitted.

Other commenters have made good points, I'll mention one I haven't seen yet. Linus has mentioned multiple times in the past that he likes to merge code it is getting used even if it's not ideal. That way, it's in the tree and can be improved instead of continuing to change outside of the kernel without the core developers' input. That's what Android's Binder is. We also have kdbus, so we know that something like this…

One very important thing to mention is that Binder is an RPC mechanism while Bus1 aims to be an IPC mechanism. The crucial consequence of that is, Binder is synchronous - you make an RPC call and you wait for the answer, while Bus1 is asynchronous - you send some data to an address and later on some data is returned to you on another address. That also necessitates the design that with Binder, the called process stea…

Adding support for priority inheritance would be a natural extension to bus1.
Post reply on HN