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

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

I really enjoy dissecting technologies, especially how it could be made better, but if we don't tread carefully, it often devolve into a religious spat

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

Do you think it's really a problem? Why would a single threaded driver be a problem when the hardware it controls needs to be programmed sequentially anyways? I'm not really sure what kind of hardware would benefit from concurrent threads trying to program it at the same time without a mutex?