Comments on: Just For Fun: The Story of Linus Torvalds http://www.pixelmonkey.org/2005/09/22/just-for-fun-the-story-of-linus-torvalds?utm_source=rss&utm_medium=rss&utm_campaign=just-for-fun-the-story-of-linus-torvalds Andrew J. Montalenti's Blog Wed, 18 Jan 2012 21:43:59 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: pixelmonkey http://www.pixelmonkey.org/2005/09/22/just-for-fun-the-story-of-linus-torvalds/comment-page-1#comment-16 pixelmonkey Thu, 06 Oct 2005 15:18:15 +0000 http://www.pixelmonkey.org/2005/09/22/just-for-fun-the-story-of-linus-torvalds/#comment-16 Right. But does that really buy you anything? If the file system daemon crashes because of some non-standard format in the bits and bytes underlying the logical organization of files and folders, don't you think the crash will just keep happening every time that read/write occurs, in which case even re-initialization of the FS daemon still gives us an unusable system. I also think that just because writing file systems as a daemon (which still has good performance) is more error prone means it will be less stable. The threat of a GPF or kernel panic in the monolithically-implemented puts pressure on developers to make sure that doesn't happen. The fact that a more stable FS layer is easier to implement in a monolithic kernel helps. And I think experience with modern-day FS layers (ext3/reiser in Linux) show that FSes end up being pretty stable even in the monolithic world. Truthfully, I don't think microkernels lead you to security or stability. They may have other benefits--like making code more maintainable and approachable, two benefits for the open source world, but we'll see how that goes. I actually really like the design of so-called 'exokernels.' My major operating systems course in school had us hacking on one such exokernel called 'jos', although we never implemented the crazy features that make exokernels fun, namely writing 'libraries' that implement traditional kernel functionality. I think the exokernel approach essentially builds upon the microkernel wisdom (keep the main kernel small), but also makes the code more manageable. Instead of daemons which talk to the kernel via message passing, you have the kernel be just another library that 'exports' resources of the hardware to application writers. If you want your own file system, you simply create your own 'libFS', and override the user's general purpose file system with your own for that application. The benefit is that you still get all the traditional UNIX applications running, but you can do things like code your own web server (with your own optimized network stack and file system) which will be much faster than Apache/equivalents running under traditional monolithic kernels. There's a great slide show on this (from 1998, but still quite valid) here: http://pdos.csail.mit.edu/exo/exo-slides/index.htm Thanks for stopping by. Right. But does that really buy you anything? If the file system daemon crashes because of some non-standard format in the bits and bytes underlying the logical organization of files and folders, don’t you think the crash will just keep happening every time that read/write occurs, in which case even re-initialization of the FS daemon still gives us an unusable system. I also think that just because writing file systems as a daemon (which still has good performance) is more error prone means it will be less stable. The threat of a GPF or kernel panic in the monolithically-implemented puts pressure on developers to make sure that doesn’t happen. The fact that a more stable FS layer is easier to implement in a monolithic kernel helps. And I think experience with modern-day FS layers (ext3/reiser in Linux) show that FSes end up being pretty stable even in the monolithic world.

Truthfully, I don’t think microkernels lead you to security or stability. They may have other benefits–like making code more maintainable and approachable, two benefits for the open source world, but we’ll see how that goes.

I actually really like the design of so-called ‘exokernels.’ My major operating systems course in school had us hacking on one such exokernel called ‘jos’, although we never implemented the crazy features that make exokernels fun, namely writing ‘libraries’ that implement traditional kernel functionality. I think the exokernel approach essentially builds upon the microkernel wisdom (keep the main kernel small), but also makes the code more manageable. Instead of daemons which talk to the kernel via message passing, you have the kernel be just another library that ‘exports’ resources of the hardware to application writers. If you want your own file system, you simply create your own ‘libFS’, and override the user’s general purpose file system with your own for that application.

The benefit is that you still get all the traditional UNIX applications running, but you can do things like code your own web server (with your own optimized network stack and file system) which will be much faster than Apache/equivalents running under traditional monolithic kernels.

There’s a great slide show on this (from 1998, but still quite valid) here:

http://pdos.csail.mit.edu/exo/exo-slides/index.htm

Thanks for stopping by.

]]> By: Travis H. http://www.pixelmonkey.org/2005/09/22/just-for-fun-the-story-of-linus-torvalds/comment-page-1#comment-15 Travis H. Thu, 06 Oct 2005 05:01:42 +0000 http://www.pixelmonkey.org/2005/09/22/just-for-fun-the-story-of-linus-torvalds/#comment-15 "That is, just because a file system is implemented as a file system daemon talking to a driver subsystem through message passing doesn’t necessarily mean the file system, or driver subsystem, are secure. Insecurity could exist even at the boundaries, no? Not to mention instability." Yes, but a crash in a file system daemon will not necessarily cause a GPF or kernel panic. You may lose the file system, but the protection boundary between the FS and kernel will isolate the kernel from the fault. So at worst it requires re-initialization of the FS daemon. “That is, just because a file system is implemented as a file system daemon talking to a driver subsystem through message passing doesn’t necessarily mean the file system, or driver subsystem, are secure. Insecurity could exist even at the boundaries, no? Not to mention instability.”

Yes, but a crash in a file system daemon will not necessarily cause a GPF or kernel panic.

You may lose the file system, but the protection boundary between the FS and kernel will isolate the kernel from the fault. So at worst it requires re-initialization of the FS daemon.

]]>