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

Bus1: a new Linux interprocess communication proposal

lwn.net

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#111

Post by tomegun »

pjc50 wrote: post #15
Pyxl101 wrote: post #7

Earlier quoted context omitted.

The design goals of bus1 are described here: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/... Some call-outs for you: > * efficiently support n-to-n communication. * be well-suited for both unicast and multicast messages. * guarantee a global message order. * avoid any in-kernel buffering and rather transfer data directly from a sender into the receiver's mappable queue (single-copy). The downside of t…

Global message order sounds like the kind of commitment that becomes increasingly expensive in a multi core environment..

The overhead due to the message ordering is constant, irrespective of the number of cores/peers. See the link posted above for an explanation.

Re: Bus1: a new Linux interprocess communication proposal

#112

Post by qwertyuiop924 »

tomegun wrote: post #106
qwertyuiop924 wrote: post #97

Earlier quoted context omitted.

What's high level? They're providing a message bus. That's not an IPC primitive. That's very high-level. As for systemd, I gathered there was a connection to kdbus, which was Lennart's baby. Thusly, I gathered it needed init to cooperate, the same way kdbus did, and any non-bus1-aware init just wouldn't work with apps that used bus1. As for portability, what other OS will implement this muck? None of them. It's porta…

Please look at the code. bus1 is no more high-level than UDS. You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc. bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic. When I said t…

Well, that's not what you said, but portability, I'll accept.

The fact that Bus1 doesn't need init cooperation is good.

However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than DBUS.

As for kdbus not being Lennart's baby, and that I should look at who wrote the code, I did. I direct you to https://lwn.net/Articles/580194/, where Lennart not only takes credit for KDBus, but also says it's application-level, implying it is intended to be used in high-level userland.

High-level abstractions for applications don't belong in the kernel.

Re: Bus1: a new Linux interprocess communication proposal

#113

Post by Annatar »

jamespo wrote: post #72
RantyDave wrote: post #39

Earlier quoted context omitted.

You can now start a zone that's compatible with 64-bit Linux, or one that runs a "hardware" hypervisor, or mix and match the two. That sort of thing?

Yes, that's interesting. Not on a par with the DTrace or ZFS projects but an incremental improvement all the same.

Not only is it on par, it's revolutionary. I'm referring to imgadm(1M) and vmadm(1M) in particular.

The guys didn't have to get out of Oracle to reinvent the wheel: the engineering they did is sound and tenable enough for decades into the future, so they built upon it.

Re: Bus1: a new Linux interprocess communication proposal

#114

Post by Annatar »

qwertyuiop924 wrote: post #91
Annatar wrote: post #77

Earlier quoted context omitted.

I think you just have a natural propensity for being smug. I chuckled when I read that, and I want you to know that I appreciated it. but if you want a UNIX on your desk, for all its flaws, Linux is pretty hard to beat. I have Mac OS X for UNIX on the desktop. Works like a charm, and never gets in the way of what I'm trying to do.

That's fine for you. Mac has traditionally been a very good option. However, I hear Apple's been making it difficult in the lastest updates. For me, anyways, it's academic, as I can't afford apple hardware.

Yep, I understand that not everybody can afford it. To me, it's was a pure, dirty capitalist investment thing: that system paid for itself hundreds of times over with all the time and effort I've saved not having to mess with it. Best money I've ever spent, what with all the time I've saved, and all the jobs I obtained with it.

Have you looked at alternatives to GNU/Linux, like PC-BSD or FreeBSD? Did you find those inadequate / too much overhead?

Re: Bus1: a new Linux interprocess communication proposal

#115

Post by tomegun »

qwertyuiop924 wrote: post #112
tomegun wrote: post #106

Earlier quoted context omitted.

Please look at the code. bus1 is no more high-level than UDS. You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc. bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic. When I said t…

Well, that's not what you said, but portability, I'll accept. The fact that Bus1 doesn't need init cooperation is good. However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than…

There is not really a permission system in bus1 any more than fd passing is a permission system. What bus1 gives you is the primitives to build a permission system though.

There is no sealing in bus1.

The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish.

kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween.

High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.

Re: Bus1: a new Linux interprocess communication proposal

#116

Post by the_why_of_y »

qwertyuiop924 wrote: post #112
tomegun wrote: post #106

Earlier quoted context omitted.

Please look at the code. bus1 is no more high-level than UDS. You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code, who submitted it upstream, etc. bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic. When I said t…

Well, that's not what you said, but portability, I'll accept. The fact that Bus1 doesn't need init cooperation is good. However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than…

> ... and includes a permissions system ...

The whole point of capability based security is that there is no permission system, because permissions are implicit in the capabilities. So this is much simpler than e.g. SysV message queues.

Re: Bus1: a new Linux interprocess communication proposal

#117

Post by hobo_mark »

rwmj wrote: post #71
digi_owl wrote: post #18

Earlier quoted context omitted.

Because the automotive industry wants to move from QNX to Linux, and wants to use dbus like they used QNX IPC beforehand. Thus we have projects like streaming video over dbus(?!). https://lwn.net/Articles/551969/

It's a shame that QNX is dying inside Blackberry. If there's one project I would love to see open sourced, it is QNX.

They tried to open it for a short period, I remember getting the sources and playing with it:

http://www.qnx.com/news/pr_2471_1.html

And now I notice it was almost ten years ago! Nevertheless, too little too late...

Re: Bus1: a new Linux interprocess communication proposal

#118

Post by qwertyuiop924 »

Annatar wrote: post #114
qwertyuiop924 wrote: post #91

Earlier quoted context omitted.

That's fine for you. Mac has traditionally been a very good option. However, I hear Apple's been making it difficult in the lastest updates. For me, anyways, it's academic, as I can't afford apple hardware.

Yep, I understand that not everybody can afford it. To me, it's was a pure, dirty capitalist investment thing: that system paid for itself hundreds of times over with all the time and effort I've saved not having to mess with it . Best money I've ever spent, what with all the time I've saved, and all the jobs I obtained with it. Have you looked at alternatives to GNU/Linux, like PC-BSD or FreeBSD? Did you find those…

I already explained: As much as I love Linux for some reasons, and would love to move away from it for many others (broaden my horizons, escape systemd), I play video games. Right now, games barely get a Linux release. If I'm on BSD or Solaris, you can forget it. And while LX-branded zones are good, I think BSD is a better system for my needs, and in any case I doubt they're good enough to get the games talking to my GPU properly. And I'd love to avoid putting another layer between the games and the hardware if I have to. I remember using Wine.

Re: Bus1: a new Linux interprocess communication proposal

#119

Post by qwertyuiop924 »

tomegun wrote: post #115
qwertyuiop924 wrote: post #112

Earlier quoted context omitted.

Well, that's not what you said, but portability, I'll accept. The fact that Bus1 doesn't need init cooperation is good. However, Bus1 is MUCH higher level than UDS. UDS is a two-way bytestream between two processes. Bus1 as much more complicated system, designed to send structured binary messages, and includes a permissions system, sealing, and a lot of other complexity. It doesn't belong in the Kernel any more than…

There is not really a permission system in bus1 any more than fd passing is a permission system. What bus1 gives you is the primitives to build a permission system though. There is no sealing in bus1. The payload of a bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish. kd…

Thanks. Sorry. I'm still not convinced that bus1 is a good idea, but at least that's been cleared up.

Re: Bus1: a new Linux interprocess communication proposal

#120

Post by saynsedit »

tomegun wrote: post #109
saynsedit wrote: post #98

Earlier quoted context omitted.

No I very much did not make it my strawman. Look at the original announcement email, they themselves list performance as their main motivation. Please, I can argue down any allegedly rationale for creating Bus1. Try me. You have yet to put forth any convincing argument. The real bottom line is Linux already has a coherent IPC system but third parties don't like it and are irrationally fixated with an in-kernel soluti…

Did you read the ksummit email? There were eight reasons given, performance was one of them (the third one). Not the only one. Not the main one.

What would you say is the main driving rationale for bus1?
Post reply on HN