Bus1 – Kernel Message Bus
bus1.org
Bus1 – Kernel Message Bus
1–10 of 67 posts
Re: Bus1 – Kernel Message Bus
#2A discussion of where Bus1 fits in the bestiary of Linux IPC proposals:
Bus1: a new Linux interprocess communication proposal
Re: Bus1 – Kernel Message Bus
#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 may be arbitrary.
How could that possibly work?
Re: Bus1 – Kernel Message Bus
#4A discussion of where Bus1 fits in the bestiary of Linux IPC proposals: Bus1: a new Linux interprocess communication proposal https://lwn.net/Articles/697191/
Someone on twitter suggested that Apple libxpc should be used. I never heard of it but if someone did, I'll be happy to know more about it.
Re: Bus1 – Kernel Message Bus
#5> 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…
See https://github.com/bus1/documentation/wiki/Message-ordering for details on message ordering.
Re: Bus1 – Kernel Message Bus
#6The 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,' in the sense that plenty of IPC research and work has been done over the last half century (or more?), and their proposals seems focused on their own small use cases. They seem unaware of how others have tried to solve the IPC problem.
On why Linus doesn't want to integrate it: no kernel team is going to want to have yet another poorly-designed IPC stack to maintain even though hardly anyone uses it. That's been done, and IPC in Unix is a mess as a result. Any sane kernel dev would be resistant to this, unless the new proposal is absolutely beautiful, and you can look at it and say, "yeah, that is really great."
RedHat should go out, investigate the research that has been done, become experts on the topic. Learn everyone's IPC problems, not just they problems they have in their own insular community. Only then create an API that actually is in good taste.
Then begin the political work of getting people to adopt it. Start with the BSD teams. Start with the hobbyist OS devs at osdev.org. When the whole world agrees that it is a good thing, then Linus will put it in the kernel too.
Re: Bus1 – Kernel Message Bus
#7A discussion of where Bus1 fits in the bestiary of Linux IPC proposals: Bus1: a new Linux interprocess communication proposal https://lwn.net/Articles/697191/
Someone on twitter suggested that Apple libxpc should be used. I never heard of it but if someone did, I'll be happy to know more about it.
Here you go: https://developer.apple.com/library/content/documentation/Ma...
It is higher level, though, it is not something you would integrate into the kernel (like bus1 intends to be). OSX has decent IPC though, since it is based on the Mach research kernel from CMU, which was kind of based around the concept of messaging to begin with.
Applescript has interesting IPC concepts as well.
Re: Bus1 – Kernel Message Bus
#8The 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 implementation, which uses Mach [2]. Don't let the similar lines-of-code count fool you—90% of the bugs that I've seen go by have been in the POSIX backend, necessitating things like manual fragmentation to get around size limits in the kernel, weird structure alignment rules in the cmsg API, file descriptor limits, ENOBUFS stuff, etc. etc. By contrast, the Mach implementation has more or less "just worked".
At this point I don't really care what the Linux kernel decides on, as long as it decides on something. kdbus or Binder or anything would have been fine; the people who are truly hurt by kernel politics are us developers.
[1]: https://github.com/servo/ipc-channel/blob/master/src/platfor...
[2]: https://github.com/servo/ipc-channel/blob/master/src/platfor...
Re: Bus1 – Kernel Message Bus
#9The 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…
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.
Re: Bus1 – Kernel Message Bus
#10The 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…
In the LWN article linked by another commentator:
"Tom Gundersen, one of the authors, acknowledged that having a dedicated system call to create a peer, and to perform the various other operations that currently use ioctl(), might make more sense for eventual upstream submission. Devices and ioctl() have been used so far because they make out-of-tree development easier."
So I think using ioctl is a prototyping concession.
I'm not an expert on this matter but I think it is the Android devs that want it not Red Hat it is similar to the android specific BINDER IPC mechanism but with multicast support.