Re: NetBSD Next Logical Step: Microkernel...?

[Martin <martin.kelly4000%gmail.com@localhost>]

On Tue, Feb 5, 2013 at 11:27 PM, <tlaronde%polynum.com@localhost> wrote:

Be careful not to confuse the advertisement about "microkernels"---I
mean the lie about the name proper---and the reality.

Plan9 was made by the fathers of Unix at a time when to be published
and acclaimed, one had to work on "microkernel". And the Plan9
paper has some ironical words about that. Because Plan9 is not a
"microkernel(TM)" but happens to be "micro" (minimal), efficient,
and for a totally distributed system. Things that "microkernels"
are unable to be at least for the 3 together. "Micro"kernels are
big; and since the efficiency is desastrous for distributed systems,
to "demonstrate" that they are the correct way they go backward to
assembly i.e. loose portability. Is Minix distributed in the same
sense as Plan9? Or is it Unix (not distributed)?

Just so you and others realize my reference to Plan 9 was purely an interest in that OS. Do you have a link to that article i would be interested in reading it. :)

Yes i do realize that there is confusion and controversy (if you want to call it that) around the name and the reality of a microkernel. Minix from my understanding runs a microkernel design with most drivers in userspace, where as i believe Plan 9 has most drivers etc in kernel space.

Just my 2 cents on the topic, but If the RUMP anykernel can run a modular kernel in any format (Micro, mono, hybrid, exo, etc..) what's the hesitation in running a development (Alpha) kernel that really pushes the boundaries of what RUMP can do? If i was persay to be running my own system (i.e. NetBSD) with a recent development that allows for modularity of the kernel to any format (RUMP); i would want to run that tool at its peak load (For RUMP that would be most kernel space tools in userspace) in the closest thing to a production environment alongside the current stable offering. That's for anything, otherwise how would i ever know if it is capable of what i have said it is at the standard that people might expect.

Although while not everyone will agree, you do in a way support my point tlaronde, as i am not talking about an overhaul or a traditional microkernel like Mach. The fact that Microkernels have there flaws only emphasizes my point that pushing the RUMP anykernel to its limitations of what it is designed to do, will not only help in examining any flaws or faults in RUMP but also pushes the development envelope of kernel design (and its always fun to be on the cutting edge of development/ research).