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

61–67 of 67 posts

Re: Bus1 – Kernel Message Bus

#61

Post by mfukar »

jasonwatkinspdx wrote: post #57
mfukar wrote: post #48

Earlier quoted context omitted.

I foresee a problem where people confuse the wording of "total order on all messages" in the wiki to mean there is a "global total order" - in other words, that bus1 solves distributed systems and we can all go home - and building buggy systems on this assumption. I'm not saying the concept is flawed or the implementation buggy, or anything like that. PS. Neil Brown in the LWN article already conflates "global" and "…

I'd suggest reading the hybrid logical clocks paper.

I have - I'm actually working with it on a multi-version IPC provider (totally unrelated to bus1 & friends). Is it relevant here? I know they're the latest and greatest, but they're not without problems either.

Re: Bus1 – Kernel Message Bus

#62

Post by gribbly »

X86BSD wrote: post #60
gribbly wrote: post #55

Earlier quoted context omitted.

Linux was GPL licensed long before these projects were open-sourced under CDDL, and there are obvious reasons for why Sun at the time would not want to have their technology advantages incorporated into Linux (like it being their main competitor to whom they were losing in the market place). Crafting a new GPL incompatible license for ZFS and DTrace resulted in Linux not being able to incorporate them.

You are simply dead wrong here. And Bryan Cantrill has said so publically. Sun NEVER intended for Linux not to adopt it. They wanted it to be ubiquitous across all open source platforms. IMO they should have two claused FreeBSD licensed it but they didn't.

Bryan Catrill says one thing.

Danese Cooper who was responsible for drafting the actual license while at Sun says another thing.

Obvious business sense stands firmly with Danese, it would be very stupid of Sun to hand over the best technological advantages of Solaris to their main competitor, which was Linux, while struggling against it in the market.

Open-sourcing Solaris was a last ditch effort from Sun to attract mindshare (and eventually market share) back from Linux, that plan would be doomed beforehand if Linux could just pick the best parts of Solaris for inclusion.

Re: Bus1 – Kernel Message Bus

#63

Post by fiddlerwoaroof »

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

What do you think of zeromq?

Re: Bus1 – Kernel Message Bus

#64

Post by ktRolster »

TD-Linux wrote: post #22
ktRolster wrote: post #9

Earlier quoted context omitted.

The reason people think that IPC is not important (and I agree with you, btw) is because so often bad designs are built around IPC. The reason Linux is opposed to integrating IPC into the kernel is because it's been done more than once, poorly, resulting in a lousy API that needs to be supported forever by kernel devs. So come up with a good solution.

What previous "bad IPC" mechanisms were integrated into mainline Linux? Only one I can think of is sysv shared memory.

All of them :)

Pipes are too specialized, localSockets are kind of a pain, etc.

Re: Bus1 – Kernel Message Bus

#65

Post by jasonwatkinspdx »

mfukar wrote: post #61
jasonwatkinspdx wrote: post #57

Earlier quoted context omitted.

I'd suggest reading the hybrid logical clocks paper.

I have - I'm actually working with it on a multi-version IPC provider (totally unrelated to bus1 & friends). Is it relevant here? I know they're the latest and greatest, but they're not without problems either.

Based on your comments about lamport clocks, etc, I thought you'd find it interesting.

Re: Bus1 – Kernel Message Bus

#66

Post by mfukar »

jasonwatkinspdx wrote: post #65
mfukar wrote: post #61

Earlier quoted context omitted.

I have - I'm actually working with it on a multi-version IPC provider (totally unrelated to bus1 & friends). Is it relevant here? I know they're the latest and greatest, but they're not without problems either.

Based on your comments about lamport clocks, etc, I thought you'd find it interesting.

It is indeed. Cool applications too. I remember at least GUN - a graph db engine - uses them to great effect, and its author hangs out here, iirc.

Re: Bus1 – Kernel Message Bus

#67

Post by pjc50 »

pcwalton wrote: post #8
ktRolster wrote: post #6

The API seems bad to me, the ioctl() is ridiculously overloaded (disconnect, connect, read, and write all go through ioctl(), for example). As an API, this doesn't pass Linus' "good taste" test. As a solution, it's more complicated than necessary. On messaging in general: this is yet another IPC api from RedHat. They really want to get an IPC api into the kernel over there. However, their proposals seem 'ignorant,' i…

I don't have much of an opinion on how good this particular proposal is, but it is important to have a sensible IPC system for Linux. I see a lot of resistance to this, with claims that Unix sockets and POSIX are good enough. As the maintainer of Rust's ipc-channel, which wraps all this stuff, I strongly disagree. The complexity of the Linux implementation of ipc-channel [1] has been absurd compared to the Mac implem…

So .. could we have Mach reimplemented in Linux?
Post reply on HN