OSNews

Overview

I have been very interested in OSes for years and have also been an avid OSNews reader, but I had never encountered this term (or Nachos in particular) before.

In Nachos' case Operating System simulator simply means, that you can run an OS (a guest OS) on top of another one (the host OS). If this sounds a little like Bochs/VMWare, then you're right, because it works similar to them. It actually features emulation for

• a CPU (a MIPS CPU)
• a hard drive
• misc. stuff like an interrupt controller, timer,...
• etc.

If you are not excited about this idea (or at least mildly interested), you have to consider what this means. People interested in OSes can easily experiment with high level matters like multiprogramming, VM organization and file systems rather than fiddling around with writing a bootloader (a task which has been tackled thousands of times by aspiring Torvaldses all over the world) first. Not to mention much easier debugging; if you want to output something from inside the Nachos kernel, just use a comfortable printf, instead of having to rely on your own console code (using BIOS, VGA,...) which might not always work reliably. Not to mention that you can easily log the debugging messages of your OS (for later thorough inspection) by simply redirecting stdout of Nachos to a file on your Host OS.

Don't get me wrong, all these low level things are of course interesting too, and fiddling around with bits, device control registers,... are be very educational (to learn how computers really work). But, these tasks can also be very frustrating. With Nachos you can get a somewhat high level overview of the task of writing an OS without all the tedious details. It could be argumented, that the low level stuff helps to weed out the meek, and only leaves the best, hardcore bit fiddlers to OS development. But I think approaches like Nachos make it easier to get the hang of OSes without all the cruft; with the experience from the highlevel view, it might be easier for people to do the low level parts.

After the basics, let's now take a look at Nachos' internals. Nachos was (/is) written with CS students and Operating Systems 101 courses in mind. The source is prepared for several assignments where different parts of the system can be explored and features implemented. I won't go into details about the source code and it's organization, since there is a lot of very good documentation about that on the web; I will instead explain some Nachos internals using the assignments.

Note: This article is concerned with Nachos 3.4, as this was the version I used in my course.

This assignment is included so people can get acquainted with the source. Nachos isn't much of an operating system yet; actually it's mostly just the implementation of a userspace thread library. To avoid confusion, we are talking about userspace from the host OS' point of view: at this moment, Nachos is nothing but kernel, and this kernel is multithreaded. There is not much else in the compiled binary; the MIPS emulation is running, but it is not used. One of the tasks (for which some stub code is already contained in the source), is the implementation of the thread synchronization facilities Lock and Condition Variable. The other part is to implement Join functionality (ie. one thread T1 can request to be blocked until a thread T2 terminates).

This is where it gets interesting and where important OS features are implemented. For many of theses features, there are already code stubs in the Nachos source. There is, eg. already a fully implemented syscall in there, complete with (MIPS) code showing how to use it from the userspace.

There is also code for the memory protection code. A class implementing code necessary for setting up an address space and reading an executable file is already in there. What you have to add, though, is code to properly handle the page tables for the processes and the processes own data, like file handles etc.

This is rather spread out over different places in the code. It starts with implementing an EXEC syscall, goes on to implementing a process table and defining process states, and doesn't stop with work on the address space again (eg. where do you have to put what, to allow your applications main() function to access parameters passed in by the EXEC syscall, ie. the argc and argv parameters. I found this rather interesting, since you deal with these things daily, but don't really know, how they actually work).

1. "NachOS, Page 1/2"
2. "NachOS, Page 2/2"