Linked by Thom Holwerda on Sat 9th Feb 2013 02:04 UTC, submitted by ac
Linux "Both of these articles allude to the fact that I'm working on putting the D-Bus protocol into the kernel, in order to help achieve these larger goals of proper IPC for applications. And I'd like to confirm that yes, this is true, but it's not going to be D-Bus like you know it today. Our goal (and I use 'goal' in a very rough term, I have 8 pages of scribbled notes describing what we want to try to implement here), is to provide a reliable multicast and point-to-point messaging system for the kernel, that will work quickly and securely. On top of this kernel feature, we will try to provide a 'libdbus' interface that allows existing D-Bus users to work without ever knowing the D-Bus daemon was replaced on their system."
Thread beginning with comment 551986
To read all comments associated with this story, please click here.
I wonder...
by sithlord2 on Sat 9th Feb 2013 10:12 UTC
Member since:

They are moving D-BUS ino the kernel, and the virtual terminals into userspace (

Are we looking here at a very careful attempt to slowly turn the Linux kernel into a microkernel?

Reply Score: 3

RE: I wonder...
by przemo_li on Sat 9th Feb 2013 11:02 in reply to "I wonder..."
przemo_li Member since:

Nope ;)

Its just adding features that are needed by modern computers.

D-Bus made huge inroads into Linux because of its value. Its hight level sockets abstraction.

AF_BUS is similar to D-Bus but in Kernel already (3.4 LTI), but its for automotive industry mostly. Something more general is cooked. And that is good.

Reply Parent Score: 4

RE: I wonder...
by moondevil on Sat 9th Feb 2013 12:09 in reply to "I wonder..."
moondevil Member since:

Not as long as Linus has anything to say about Linux development as he opposes to micro-kernel architectures.

Reply Parent Score: 5

RE[2]: I wonder...
by JAlexoid on Sun 10th Feb 2013 00:10 in reply to "RE: I wonder..."
JAlexoid Member since:

Well... We all know how that discussion ended last time.

"F**k you nVidia!" Is child's play ;)

Reply Parent Score: 2

RE[2]: I wonder...
by butters on Sun 10th Feb 2013 00:27 in reply to "RE: I wonder..."
butters Member since:

Really? FUSE and udev were implemented under his watch. Linus is not a very ideological person. He opposed microkernel architecture for pragmatic reasons, mainly because running device drivers in userspace leads to poor interrupt response times.

But as we've seen with hybrid kernels like NT and XNU, there is still value to microkernel architecture even if the device drivers and resource abstractions are mapped onto every address space for performance reasons.

If Linux had embraced a more microkernel-like architecture with a kernel message bus, we might have avoided the whole saga of excising the Big Kernel Lock and the BH device drivers which severely hampered the kernel's ability to scale on SMP hardware.

There is still a stigma in the Linux community about microkernel design aesthetics, probably best demonstrated by the meager adoption of the workqueue interface introduced in the 2.5 series. This allows drivers to queue their work to run on a pool of kernel threads, where they can use sleeping locks and blocking I/O for easy concurrency. But the inclination is to avoid sleeping or blocking and use tasklets instead, even though tasklets are strictly serialized against themselves and do not scale on SMP hardware.

Here we are in 2013, and we're still so worried about the overhead of switching a stack pointer that almost all of our device drivers are single-threaded, and the few that aren't (network and scsi) resort to per-cpu data structures and other tricks because they are running in interrupt context and cannot block.

Reply Parent Score: 3

RE: I wonder...
by galvanash on Sun 10th Feb 2013 00:48 in reply to "I wonder..."
galvanash Member since:

Are we looking here at a very careful attempt to slowly turn the Linux kernel into a micro-kernel?

There is a helluva lot more to a micro-kernel than just providing IPC. You have to actually start using it for in-kernel stuff. For example, I don't see DBUS being used underneath the syscall interface anytime soon (or ever), but once its firmly in the kernel it could make sense for a few things where simplicity and flexibility trump performance. If a truly logical argument for such a usage case is ever made, I don't really expect that their would be much resistance - even from Linus. Even then, selective use doesn't turn Linux into a micro-kernel - its just pragmatism.

Reply Parent Score: 4