It is however moving in that direction. More and more the components and drivers are communicating via the message bus for which the user mode access is handled via a separate process.
And as far as stability vs experimental well you are not wrong. Hurd is an experimental design ment to be a proving ground for a radical rethink of how a kernel should operate, where as linux has always been about getting it working even if it doesn't do every thing under the sun the way you would theoretically like it to. That's why I have never proposed installing Hurd at work.
That being said if you want to continue this conversation off the list I would be happy too, but this has gone way off the topic of the original thread and even the list its self
-- Sent from my HP Pre3
On Mar 1, 2013 10:45 AM, David Sommerseth <sl+us...@lists.topphemmelig.net> wrote:
On 01/03/13 15:06, Paul Robert Marino wrote:
> Have you run a ps -ax on a Linux box lately? You call that monolithic?
> The linux kernel has been migrating to a micro kernel slowly for the
> last decade now. In some ways its benefited from its older cousin GNU
> Hurd because the Linux Kernel developers had the benefit of knowing what
> went wrong and what worked well in Hurd. By the way from my
> understanding one of the things they really got wrong was using Mach as
> a base because it was the root cause of a majority of the issues they've
> had, and last I herd they were stripping Mach out of the Hurd kernel.
I'm sorry, but the Linux kernel is far far far from a microkernel. It
does indeed have loadable modules support, kernel threads running as
separate tasks (including IRQ threads) and such things. But those
threads have full access to global variables in the kernel and the
general design of the Linux kernel is monolithic.
The traditional microkernel design have separate processes which lives
in their own memory spaces, only communicating through a message bus.
This is far from what the Linux kernel is today.
And to be honest, I honestly doubt Linus want to make the Linux kernel a
microkernel; if you've read about what Linus' opinions is about the
microkernel design.
"Personally, I'm not interested in making device drivers look like
user-level. They aren't, they shouldn't be, and microkernels are
just stupid. " (2002-05-25, Linus Torvalds)
<https://groups.google.com/forum/?fromgroups=#!msg/mlist.linux.kernel/avl2ZFiVRw8/etxgrob6j5MJ>
"<odd>.x.x: Linus went crazy, broke absolutely everything, and
rewrote the kernel to be a microkernel using a special message-
passing version of Visual Basic. (timeframe: "we expect that he
will be released from the mental institution in a decade or two")."
(2005-03-02, Linus Torvalds)
<https://lkml.org/lkml/2005/3/2/247>
"... even if the Hurd didn't depend on Linux code (and as far as I
know, it does, but since I think they have their design heads
firmly up their *sses anyway with that whole microkernel thing,
I've never felt it was worth my time even looking at their code)..."
(2006-09-27, Linus Torvalds)
<https://groups.google.com/forum/?fromgroups=#!msg/fa.linux.kernel/V5Njq8zcZt4/8dDRu5RyYeQJ>
"We're not masturbating around with some research project. We never
were. Even when Linux was young, the whole and only point was to
make a *usable* system. It's why it's not some crazy drug-induced
microkernel or other random crazy thing. "
(2012-03-08, Linus Torvalds)
<https://lkml.org/lkml/2012/3/8/495>
And of course, you have the classic Tanenbaum-Torvalds debate as well.
<http://en.wikipedia.org/wiki/Tanenbaum-Torvalds_debate>
--
kind regards,
David Sommerseth
> ------------------------------------------------------------------------
> On Mar 1, 2013 12:13 AM, zxq9 <z...@zxq9.com> wrote:
>
> On 03/01/2013 01:03 PM, Yasha Karant wrote:
>> Modern BSD is a micro-kernel ("MACH") design, whereas Linux still is a
>> monolithic kernel design...
>
> implying...
>
> That monolithic kernel design is demonstrably primitive in every respect
> to micro-kernel design and that there is a universal evolutionary path
> predicted by some law we have yet to discover.
>
> That kernel design trumps driver availability in every respect.
>
> That any of this matters since nobody is fronting the development time
> to implement $astronaut_arch_X.
>
> That this is the place to discuss this.
