Linked by Thom Holwerda on Wed 9th Nov 2011 21:26 UTC, submitted by edwin
Permalink for comment 496948
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



Member since:
2005-07-06
I think because of the rich commentary available with V6 UNIX (Ie. the Lions book), and V6 is very simply.
In fact, I'd go so far to say that the V6 kernel would probably make for a reasonable base of a micro-kernel with a bit of work.
But as it is, V6 is still a monolithic kernel, with all the OS services linked into kernel space, whereas Minix provides only critical services that cannot operate in user space, leaving the rest to user space servers.
I'm torn on the micro versus monolithic kernel debate. Some services are not really restartable without hacks that obviate the benefits of a micro-kernel in the first place (how would you restart the filesystem server if you can't read the filesystem server binary from the filesystem? You'd have to link it with the kernel blob, meaning it couldn't be changed at run time).
The original Minix version was 16-bit and probably not well integrated with development tools like GCC and GDB.
It was a pleasure just typing "make qemu-gdb" and attaching running a debugger in another window, and stepping through the kernel as it did it's work. I guess it'd take a lot of work to get Minix into that state.