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 551992
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: I wonder...
by moondevil on Sat 9th Feb 2013 12:09 UTC in reply to "I wonder..."
moondevil
Member since:
2005-07-08

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:
2009-05-19

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:
2005-07-08

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[3]: I wonder...
by Alfman on Sun 10th Feb 2013 02:22 in reply to "RE[2]: I wonder..."
Alfman Member since:
2011-01-28

butters,

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

Reply Parent Score: 5