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

101–110 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#101

Post by the_why_of_y »

qwertyuiop924 wrote: post #97
tomegun wrote: post #92

Earlier quoted context omitted.

What's high-level about bus1? This has nothing to do with systemd, and very little (apart from history) to do with kdbus. As to portability, this is a linux kernel module, but there is nothing really inherent to linux about it, so porting it to another kernel should not be a lot of work if that is interesting to anyone.

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…

None of QNX IPC, Mach IPC, Minix3 IPC, Solaris Doors, NT LPC or Android Binder is portable, and all of them are used by low-level user-space on their respective platform. But if Linux developers add a new IPC mechanism for similar purposes, it must be useless "muck"?

Re: Bus1: a new Linux interprocess communication proposal

#102

Post by qwertyuiop924 »

the_why_of_y wrote: post #101
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…

None of QNX IPC, Mach IPC, Minix3 IPC, Solaris Doors, NT LPC or Android Binder is portable, and all of them are used by low-level user-space on their respective platform. But if Linux developers add a new IPC mechanism for similar purposes, it must be useless "muck"?

NT doesn't have to worry about compat. Neither do Android apps. QNX, Mach, and Minix3 are microkernels, and that IPC isn't used by high-level userland in the UNIX compatible systems. Doors is something I have similar objections to.

But if bus1 is a successor to kdbus, it's not intended to be used by low-level userland, it's built for highlevel userspace. Like systemd, this is trying to coax high-level userland to be incompatible with other unixes.

The fact that no unixes other than the originating one, if the orginator was a unix, has picked up any of these systems speaks volumes about why you shouldn't use it in highlevel userland.

Re: Bus1: a new Linux interprocess communication proposal

#103

Post by Annatar »

cyphar wrote: post #88
Nursie wrote: post #44

Earlier quoted context omitted.

You exhibit a weird mixture of snobbery and incompetence. How odd.

I've decided to stop interacting with Annatar, it's not worth the rage. Especially when he starts misrepresenting GNU/Linux technology that you are deeply into the development of (runC and containers in my case).

Part of engineering a good solution is being able to recognize when you are in knee deep, and that it's not the best solution, and ditch it. That's what turns a good engineer into a great one, because then she or he turns around and builds the solution. You might not believe the grandpa here, but you're in knee deep, if not deeper.

On a personal note, I'm happy that you've stopped interacting with me. Good luck.

Re: Bus1: a new Linux interprocess communication proposal

#104

Post by Annatar »

vidarh wrote: post #89
Annatar wrote: post #60

Earlier quoted context omitted.

Don't underestimate the importance of people. This warrants a reply of its own, since it is the core idea of my essays: it is the very difference between a stable, working, reliable product and Linux: the people. The right people. Competent people . People with the neccessary education, experience, and insight . If if ever need heart surgery, I guarantee you that I won't go to the local shaman, no matter how happy he…

But 99% of what we do are not that of heart surgery. Much of it is playing. Much of it is experimenting. Much of the actual work needs flexibility, familiarity and community more than it needs technical excellence. Which is why I wrote what I did. Your reply manages to turn it entirely on its head. People believe computer science is different from surgery because it is : Nobody dies when my half-assed experiments wit…

But 99% of what we do are not that of heart surgery. Much of it is playing. Much of it is experimenting.

And it shows. However, just because you can get something to work, in some way, does not suddenly make you (or anyone else) a professional. Case in point:

http://meta.serverfault.com/questions/6229/frustration-when-...

...Nor does it make your playful experiment fit for production where people like me are trying to get work done.

"I got something to work. Because Linux! Because community! Um... I think I'll go get a job as a computer professional now. What could possibly go wrong? Linux is so awesome!"

People believe computer science is different from surgery because it is: Nobody dies when my half-assed experiments with OpenGL crashes. Nobody dies if my laptop crashes.

An operating system's kernel is an extremely complex, special piece of software. A bug in such software can cause many people to die, which is why someday you might see disclaimers about running a nuclear facility and fitness of purpose. (Interprocess communication, the original topic, is part of an operating system's kernel.) Writing and diagnosing such software requires very deep insights, which very few have, even among computer professionals. Additionally, it absolutely and without fail requires formal education in the problem domain, it requires experience, and it requires apprenticeship, and I'm writing about physical one on one mentorship. It's not something one can pick up "from the community", never has been, and never will be, and if anybody tells you any different, they're either dangerously ignorant, or lying to you for the purpose of their own agenda.

Experimenting is all good and well, but when the entire armies of you start deploying your experiments in production and it becomes a trend and then the rest of us are, in fact, forced to take on such jobs because there aren't better ones, then it becomes a systemic problem. Not to mention that armies of you are currently in the process of artificially driving salaries down and it will be years before the market self-corrects, so make that a double whammy.

Now, me, I don't so much mind that cheap Linux labor is artificially driving salaries down, since cream always rises to the top, as they say, but I do so very much mind being forced by contract to work with things like ext3, which is based on concepts from the past century and which have since been long abandoned elsewhere, or that my really cool super slick database becomes unstable because of your experiment ticking underneath it (and before you ask, if it were up to me, I'd never put my database on your experiment). I mind even more when your (plural) experiements end up causing a priority 1 incident in the wee hours in the morning, when I'm busy getting my beauty sleep. In my case, you see, it's "because client contract!" Slightly different slant on things than in your case. Welcome to the industry.

Re: Bus1: a new Linux interprocess communication proposal

#105

Post by [deleted] »

pjmlp wrote: post #85
saynsedit wrote: post #73

Earlier quoted context omitted.

Irrelevant, if the vast majority of modern packages work with the big three, it's highly likely they work with other conforming POSIX systems.

The keyword being likely . I don't miss my days of writing portable POSIX code across DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian and the respective #ifdefs.

[deleted]

Re: Bus1: a new Linux interprocess communication proposal

#106

Post by tomegun »

qwertyuiop924 wrote: post #97
tomegun wrote: post #92

Earlier quoted context omitted.

What's high-level about bus1? This has nothing to do with systemd, and very little (apart from history) to do with kdbus. As to portability, this is a linux kernel module, but there is nothing really inherent to linux about it, so porting it to another kernel should not be a lot of work if that is interesting to anyone.

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 that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...

Re: Bus1: a new Linux interprocess communication proposal

#107

Post by tomegun »

rwmj wrote: post #69
qwertyuiop924 wrote: post #45

No. Nonononononononono. We were ALMOST FREE! Just get these high-level abstractions out of my effing kernel. They don't belong there. Linus said as much himself. The only reason kdbus, this thing's predecessor, got so much as a glance is that Linus trusts Greg KH. A trust I would now consider somewhat misplaced. This is yet another piece of crap that was tacked on by systemd nonsense. It's non-portable, and they want…

I thought the interesting part of kdbus was the "memory sealing" - you could take a shared memory buffer, write to it, then "seal" it (so no further changes were allowed) and share it with another process. I believe you cannot efficiently do that in userspace. That doesn't seem to be part of this proposal.

memory sealing can be used by anything that can do fd passing, which bus1 does (as does UDS). That code is already upstream and was not really tied to kdbus.

Re: Bus1: a new Linux interprocess communication proposal

#108

Post by tomegun »

f2f wrote: post #10

"To create a new node, an application performs any of the various ioctl() operations that accept a handle, passing the special reserved handle number of "3". what a bunch of jokers :)

Hehe, that was the only part of this article I didn't particularly love. This is how it works: A handle ID is a 64bit integer. If lowest bit (BUS1_NODE_FLAG_MANAGED) is set it is a handle ID allocated by the kernel (the only mode currently supported). If the second lowest bit (BUS1_NODE_FLAG_ALLOCATE) is set a new handle should be allocated by the kernel, otherwise the handle ID must refer to an existing handle.

Re: Bus1: a new Linux interprocess communication proposal

#109

Post by tomegun »

saynsedit wrote: post #98
deno wrote: post #96

Earlier quoted context omitted.

You seem to be fixated on this idea that this is purely a performance optimization. You’ve made it your strawman. But that is in fact only one minor point. Linux is lacking a coherent IPC system and the necessary primitives to build one. That’s the bottom line.

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.

Re: Bus1: a new Linux interprocess communication proposal

#110

Post by qwertyuiop924 »

saynsedit wrote: post #98
deno wrote: post #96

Earlier quoted context omitted.

You seem to be fixated on this idea that this is purely a performance optimization. You’ve made it your strawman. But that is in fact only one minor point. Linux is lacking a coherent IPC system and the necessary primitives to build one. That’s the bottom line.

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…

>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 solution that reflects their grand idea of what a coherent IPC system should look like. It's childish, it's bad engineering, and it's a waste of effort.

Finally, He said what we're all thinking!

Post reply on HN