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."
Permalink for comment 552014
To read all comments associated with this story, please click here.
RE[2]: I wonder...
by butters on Sun 10th Feb 2013 00:27 UTC in reply to "RE: I wonder..."
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