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

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

Tim Larson <Tim.Larson%proxibid.com@localhost> wrote:

> You
 bring up several good points. I believe these are the main reasons that
 Minix has decided to use NetBSD userland, libc, and pkgsrc.
> Tim

Totally agree. I wouldn't be surprised if Minix eventually adopt the NetBSD toolchain too. The benefits for Minix is huge and i wouldn't mind betting that once Minix has ported the NetBSD userland, libc and pkgsrc they will be a huge benefit in terms of development from them.

Although i also think (not that my opinion will matter in the grand scheme of things) that while NetBSD have stuck with a monolithic kernel for reasons that are obvious and the not so obvious, i really do believe that if a microkernel existed for NetBSD (even as an alternative kernel to Xen & generic) it would really benefit both development for NetBSD and knowledge of Microkernels and how to improve them. What i mean by benefit development is that developers could really push development of drivers and new tools without worrying about kernel incompatibilities or system failures from bad code etc.

Bare with me while i put forward my idea:
Lets take for example the idea of running two different kernels for NetBSD the generic mono kernel and a microkernel. With the current toolchain and the RUMP anykernel the ability to transfer software development between the two wouldn't be much harder than transferring it between different platforms (i.e. sparc64 to amd64). What i am suggesting is basically using the microkernel design as development platform for NetBSD software & tools, lets take the development of KMS and GEOS drivers for the running graphic acceleration and in the use of the nouveau video drivers. Most know that by running drivers in userspace they are easier to debug and develop for because won't cause huge problems if some goes wrong as it doesn't shut down the whole system. Which for the development of the GEOS and KMS tools is big.

While it all comes down to manpower the only real big development is actually making the microkernel, which in all honesty with RUMP wouldn't be anywhere near as complex or difficult as what Minix had to do between version 2 and 3.