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

81–90 of 139 posts

Re: Bus1: a new Linux interprocess communication proposal

#81

Post by dooglius »

lathiat wrote: post #51
IshKebab wrote: post #48

Earlier quoted context omitted.

I agree. I can't see any real reason for this to be in the kernel. Is it faster? Does it need access to memory in some way you can't do in userspace? The only practical reason I can think is if it is in the kernel you can 100% rely on it being present and available. Userspace processes can be killed. So perhaps the real solution is to provide some kind of mechanism for userspace processes that act like kernel drivers…

The two main reasons I know/care about (there may be more) are that it can be much faster (zero copy, reduced context switches) and also guarantee the message isn't changed while reading (by sealing the originating buffer). The last is something you need kernel help to enforce.

I don't see anything described that can't be done in a userspace library through shared memory. Maybe security is a concern, where we don't trust some nodes that might be exploited not to be able to screw with the shared memory? But then zero-copy would be off the table for the same reasons, no?

Re: Bus1: a new Linux interprocess communication proposal

#82

Post by deno »

saynsedit wrote: post #80
deno wrote: post #79

Earlier quoted context omitted.

You’re ignoring the fact that Bus1 is based on binder, not dbus, so performance (mostly power efficiency) apparently was an issue—on Android. So now you have two ends of the spectrum where this effort does matter, performance wise. This only leaves the middle (desktop), but there are other reasons why that evil desktop crowd wants IPC in kernel, however high on a ‘priority list’ they might be.

My point still stands. I don't think it's very likely that the main power hog in a mobile phone is the IPC mechanism. Unless IPC is happening in a tight loop, on the order of millions if times per second, it's just not common enough to really make a dent. You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.

http://lwn.net/Articles/504984/ #Priority Inversion #Latency

It’s not about tight loops.

Also this idea that you have to fix wifi chip or screen before you can add anything to the kernel doesn’t seem to be founded in any kind of logic.

Re: Bus1: a new Linux interprocess communication proposal

#83

Post by naasking »

goalieca wrote: post #78
naasking wrote: post #59

Earlier quoted context omitted.

> It leaves me scratching my head because I don't think serialization is that hard a problem. It is a hard problem, at least if you want to achieve concision, make it parseable, and support schema upgrade. > "Traditional POSIX threading models, IPC interfaces, and file system access are being replaced by platform and vendor-specific APIs and frameworks such as Grand Central Dispatch [18], Binder [29], DBus [25], and…

Serialisation is its own problem. Should have nothing to do with IPC. Layered architectures out the window in favour of systemd like monoliths.

> Serialisation is its own problem. Should have nothing to do with IPC.

Yes and no. There's significant utility to standardizing serialization in your IPC layer. IPC consists of exchanging domain-specific messages, so the message types can be specified in a header shared between endpoints, and data gets serialized in a standard format.

The IPC API then simply reduces to sending/receiving data to/from endpoints, like channels in CPS. And ideally it should be higher-order so you can send an endpoint to another endpoint.

So you don't need to standardize the serialization, but then you just get a plethora of incompatible formats.

Re: Bus1: a new Linux interprocess communication proposal

#84

Post by [deleted] »

deno wrote: post #82
saynsedit wrote: post #80

Earlier quoted context omitted.

My point still stands. I don't think it's very likely that the main power hog in a mobile phone is the IPC mechanism. Unless IPC is happening in a tight loop, on the order of millions if times per second, it's just not common enough to really make a dent. You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.

http://lwn.net/Articles/504984/ #Priority Inversion #Latency It’s not about tight loops. Also this idea that you have to fix wifi chip or screen before you can add anything to the kernel doesn’t seem to be founded in any kind of logic.

[deleted]

Re: Bus1: a new Linux interprocess communication proposal

#85

Post by pjmlp »

saynsedit wrote: post #73
pjmlp wrote: post #70

Earlier quoted context omitted.

There are more UNIX flavours than those ones.

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.

Re: Bus1: a new Linux interprocess communication proposal

#86

Post by saynsedit »

deno wrote: post #82
saynsedit wrote: post #80

Earlier quoted context omitted.

My point still stands. I don't think it's very likely that the main power hog in a mobile phone is the IPC mechanism. Unless IPC is happening in a tight loop, on the order of millions if times per second, it's just not common enough to really make a dent. You have wifi, screen brightness, CPU-hungry background apps, etc. to fix first.

http://lwn.net/Articles/504984/ #Priority Inversion #Latency It’s not about tight loops. Also this idea that you have to fix wifi chip or screen before you can add anything to the kernel doesn’t seem to be founded in any kind of logic.

I don't buy these arguments...

For priority inversion it seems dbus-daemon is at fault here, not user-space message routing in general. It's just as easy to have two message routing processes, one for low priority messages and one for high priority messages.

As far as 4 context switches versus 2 with regards to latency. A context switch takes microseconds... This is vastly smaller than the 250ms UI response time.

Again, this looks like a solution looking for a problem.

Fixing wifi or screen before working on micro-problems in the kernel for the sake of global power efficiency is founded in every kind of logic. It's literally Amdahl's Law: reducing power usage in a component that already has the most minimal power usage is a waste of effort for no noticeable effect. The cost-benefit ratio is indefensible. This is insanity.

Re: Bus1: a new Linux interprocess communication proposal

#87

Post by saynsedit »

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.

This is still irrelevant.

You were asserting that the majority of programmers think Linux == UNIX and have never tried to write a portable application.

Thst is clearly false as the majority of programmers probably confuse Mac OS X for UNIX and most modern unix-like software is portable to at least Linux, Mac OS X, and FreeBSD. Portable is more general than "portable across every UNIX that has existed."

Increasing the specificity of your argument mid-way to avoid the incorrectness of your initial general argument isn't very genuine.

But yes, your revised second statement is probably correct: most UNIX programmers have never tried writing portable code across "DG/UX, Solaris, HP-UX, Aix, FreeBSD, Red-Hat, Debian" exactly because there is no practical reason for it.

Re: Bus1: a new Linux interprocess communication proposal

#88

Post by cyphar »

Nursie wrote: post #44
Annatar wrote: post #42

Earlier quoted context omitted.

to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag, and spend more time arguing with paying customers back-and-forth in redhat's bug system, because they don't have a clue where the problem is ? When you have so…

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).

Re: Bus1: a new Linux interprocess communication proposal

#89

Post by vidarh »

Annatar wrote: post #60
vidarh wrote: post #28

Earlier quoted context omitted.

It will always be in flux because it reflects what Illumos doesn't have: A userbase as diverse and large as Linux, of which a large proportion have competing needs and wishes and the ability to change it at will . This is not just about license either, but about the availability of people who understand the kernel. I'm sure we could have something cleaner with a single, coherent team. But we also would have something…

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 with OpenGL crashes. Nobody dies if my laptop crashes.

There are certainly niches where it is life and death. Let others take care of that - I don't want anything to do with it.

Re: Bus1: a new Linux interprocess communication proposal

#90

Post by vidarh »

Annatar wrote: post #42
vidarh wrote: post #28

Earlier quoted context omitted.

It will always be in flux because it reflects what Illumos doesn't have: A userbase as diverse and large as Linux, of which a large proportion have competing needs and wishes and the ability to change it at will . This is not just about license either, but about the availability of people who understand the kernel. I'm sure we could have something cleaner with a single, coherent team. But we also would have something…

to the ability to hire any of a "an army" of past or current kernel developers to help solve my problems or do my custom development Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag, and spend more time arguing with paying customers back-and-forth in redhat's bug system, because they don't have a clue where the problem is ? When you have so…

> Aha, you mean like redhat and IBM did, where there are now "kernel developers" who can't find their way out of a wet paper bag,

No, I mean like I can find any number of actual maintainers with a known track record and make them an offer to pay to have work done. Been there. Done that. Got good results.

> in order to have a look at what your presumption looks like in the real world...

It's not a presumption. It's actual experience in finding people to do work.

> ...Because we need more beta filesystems

Not everything is about need. While I work full time with Linux, a lot of what I use my computer for is fun, experimentation, learning. So yes: We need more beta filesystems. It's great that people experiment and learn. Everyone should try their hand at kernel changes, to learn - it's not magic.

> ...which ext3, which was on this Veritas disk group, wasn't able to recover, let alone detect. In the 21st century. Because community. I last saw a problem like this on Solaris ten years ago, since it has been a solved problem since 2006 there. Bryan is correct, I do have clean water, and even modern medical care facilities!

So use Solaris then, if you have so many problems with Linux. We're not forcing you to use Linux. It's not a dictatorship. I'll happily admit to all kinds of warts in Linux - I explicitly made the point that Linux has plenty.

> I have zero interest in how much of a community Linux has

Good for you. Meanwhile, for me, the community makes all the difference in making sure that I, e.g., has a decent sized hiring pool at all levels when I need developers, or which means that pretty much no matter what I try to do, there are people who have done it before I can ask questions of.

To me, that matters far more than avoiding a few warts.

Post reply on HN