System verification and final thoughts

In order to verify that my low-power modifications had not fundamentally altered or even minorly regressed the behavior of the Xinu OS, I designed two simple tests: a scheduling test and a millisecond sleep test. These tests are written as two programs launchable from the shell. The first is a basic millisecond sleep interface, which allows the shell user to perform sleeps with millisecond accuracy. The second is a pair of commands called spawn_incprio and spawn_decprio that spawn 5 processes of increasing priority and decreasing priority, respectively. These processes will complete in order of highest priority to lowest priority, regardless of which command is given.

All three commands were tested on a stock Xinu image as well as my custom low power image, and were verified to work in exactly the same way on both. Their source is provided along with the rest of the Xinu source code that I used to create my low power consumption Xinu OS.

FINAL THOUGHTS

In the course of the development of this low power variant of Xinu, I read and analyzed about 60% of the source code of the OS itself (found in the system and include directories), and about 50% of the shell process code as well. I did not spend any time looking at the device/tty code, though I imagine it would be interesting, and perhaps the source of some strange printf buffering issues I observed while playing with the stock Xinu image. The scheduling subsystem, and in particular the ctxsw assembler routine (which sets up the stack and registers to look as though they are in a function that was called by the new process, and then "returns" from that function), were very interesting because of the way that they seamlessly transfer control from one process to another without . But, to me, the most interesting of all was definitely the interrupt subsystem. The x86 architecture is interrupt-driven, and it seems that a large part of the functionality of an x86 OS depends on its ability to properly manage and handle interrupts, both as external sources of I/O and as an internal process management tool. It would be very interesting to investigate a multicore OS such as Linux to see how it manages handling IRQs on multiple cores without losing parallelism. Further, it would be interesting to attempt to change Xinu into an operating system that operates in protected mode instead of real mode, by converting the various system calls into functions that perform a software interrupt, and then providing software interrupt handlers that transfer control to the actual system calls themselves and eventually return control to the processes via normal scheduling algorithms.

I learned even more than I imagined I would, and I highly recommend Xinu as a study tool for others trying to understanding how an operating system actually does what it does. While Xinu is certainly much simpler than most OSes in use today, the foundational concepts that it requires you to truly understand in order to tinker with it allow the user to begin to actually grasp the more complex realities that face a modern OS.