DBus

Because it is so good we need it in the kernel.
http://www.phoronix.com/scan.php?page=news_item&px=MTgyNTQ

Torvalds will accept pretty much anything in his kernel as long as the feature is GPLv2 compatible and the features do not conflict with his own vision of Linux.

Which 3 letter agency does this ^qqGreg^pp work for?

For over four years Linux developers have been talking about bringing D-Bus into the kernel as a low-level, native kernel DuB-s transport for inter-process communication (IPC).

check 'em

It's shit like this that almost makes me wish microkernels had won out on general purpose systems. If you're going to have just one IPC mechanism it had better be good.

D-Bus is a free and open-source inter-process communication (IPC) system, allowing multiple, concurrently-running computer programs (processes) to communicate with one another.

Why the fuck do we need yet another bloody IPC API?

The kernel already has these:

http://linux.die.net/man/7/fifo
http://linux.die.net/man/7/pipe
http://linux.die.net/man/7/mq_overview
http://linux.die.net/man/7/unix

I wish they merge Firefox into the kernel too!

LINUX DIE

Dubs

>>11
excellent dubs

>>10
You too

uns

>>6
Keep in mind, D-Bus is not only an IPC system; it also includes lifecycle tracking, service activation, security policy, and other higher-level structure and assumptions.

The best place to start is to read the D-Bus tutorial, so you have a concrete idea what D-Bus actually is. If you understand other protocols on a wire format level, you may also want to read the D-Bus specification to see what D-Bus looks like on a low level.

As the tutorial and specification both explain, D-Bus is tuned for some specific use cases. Thus, it probably isn't tuned for what you want to do, unless you are doing the things D-Bus was designed for. Don't make the mistake of thinking that any system involving "IPC" is the same thing.

It should be possible to bridge D-Bus to other IPC systems, just as D-Bus can be bridged to object systems.

>>1

DBus

lol you mistyped dubs
but good topic!

>>6,13
The principal objection here is that such high level services don't need to be embedded in the kernel. The kernel already provides more flexible low level services that multiple high level frameworks can use.

A lot of the blame for D-Bus support being added to the kernel can be laid at the feet of the maintainers for existing IPC subsystems who refused to support D-Bus use cases.

>>15
D-bus doesn't need to be inside the kernel and you can remove if that's what you want; Linux doesn't rely on Kdbus; Kdbus is an optional module that is easy to disable.

>>16
You are aware that the current D-Bus maintainers have no intention of continuing support for the user space only daemon, right? It won't be long before kdbus is neither optional nor easy to disable (not for people using mainstream desktop environments, anyway).

install solaris

>>6
You have listed 4 shitty ones.
First and foremost there are signals, and especially RT signals. Those are hot bitches.

>>17

You are aware that the current D-Bus maintainers have no intention of continuing support for the user space only daemon, right?

Yes I did know and I personally don't care because I don't see any serious consequence to me. I don't know what it takes to fork dbus1 but I'd guess that it won't be to maintain feature parity with Kdbus. I'm basing this on the assumption that the d-bus specification is relatively stable and that there are no planned changes that'll significantly impact the specification.

>>19
Signals are the worst, you fucking degenerate.

c

h

e

c

k

e

m

d

u

b

s

>>22

nice dbus, i want to suck your cock :3

>>23
But do you want to take is dbus in and merge it with the kernel of your being?