To view parent comment, click here.
To read all comments associated with this story, please click here.
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.
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?





Member since:
2005-07-08
Not as long as Linus has anything to say about Linux development as he opposes to micro-kernel architectures.