Student Operating System?



  • When I was in college there was this thing called a "Student Operating System", its an old C mechanism with callback methods where a student can write interrupt handlers and manage process scheduling and memory/swapping. The system is a simulation of a computer with processes needing service and the student implements the recource allocation.

     

    The project is old (it still refers to hdd as the drum) and does not support paging. So basically this teaches the students almost nothing by actually implementing a modern operating system requirements. (this would have been useful for an OS from the 70s or 80s)

     

    Does anyone see any value in re-implementing this thing in say Java (so implementations can be in Java, Jython, Groovy) with more useful modes like having students implement processor scheduling, swapping, and paging algorithms and to see how much more efficient everything is. This way when assignments are given, the students can be given a target efficiency and must implement as efficient algorithms as they can for all 3 parts to get throughput as high as possible.

    Is it worth doing? Is this work useless and students should just read a book?



  • Worth doing or read a book?  How about both? 

    Ray Ontko and Alexander Reeder have written such a program in Java as a companion to Tanenbaum's Modern Operating Systems (2nd Ed). It's called "MOSS" (Modern Operating System Simulator).  Theirs seems directed at specific areas of interest rather than being a general simulator.



  •  There's also NACHOS.



  • @dlikhten said:

    Does anyone see any value in re-implementing this thing in say Java
     

    I think that this is definitely worth doing, as actually implementing a lot of the techniques are, imho, a much better teaching tool than only reading about the different mechanisms.

    I'm not sure about the use of a "simulator" or virtual computer though. Why not let students write the whole operating system? My University offers a one semester lab that involves building an operating system from scratch. We use the x86 architecture and Java as the programming language. I'm not really convinved by the use of Java, as you need a special compiler that supports "most" of the Java 1.4 features and will produce x86 assembler code together with a small boot loader.

    If you can find / create a small build environment to take c/c++/$language code and produce a bootable image from that, then this approach would be perfect. There are some absolutely outstanding x86 simulators and virtualization environments around, QEMU and Bochs for example. Bochs includes an incredible debugger that allows you to step through the machine cycles and track down otherwise difficult to find bugs (anything from virtual memory to device drivers can be easily debugged.)

    VMware server and Microsofts Virtual PC are other free of charge tools that can be used to test the OS, and with bootable media it runs on actual x86 hardware.

    We did things like:

    - building a bootable image, and doing text-mode output

    - Keyboard / mouse input using the PS/2 controller

    - command shell 

    - Interrupt handling, exception handling (including register-dump and stack traces on critical failures)

    - virtual memory

    - multiple tasks and task switching 

    - IDE disk access, I think we used PIO

    The last assignment was something each group could choose for themselves, and we did anything from file system access (FAT32) to graphical UIs and I think even some network support.

    It was a very neat lab, and groups of two can get very far in one semester. 



  • My university (University of Waterloo) taught NachOS as a required course in third year (and I believe it still does). We didn't do much, just scheduling, IPC, filesystem, memory management and other basics. But I honestly don't think I'd readily trust code written by someone who doesn't understand these basics. Especially not code that involves resource management and/or concurrency in any shape or form.

    In fourth year, an optional course I took was very similar to what Nandurius described, but with emphasis on microkernels and their applications rather than on theory (which was already covered in the NachOS course). Groups of two would build a priority-based scheduler, simple blocking IPC protocols and interrupt handling, then add on driver, service and application layers to their system, eventually making a system that would control a model train set connected to the PC via serial. Everything was written in C/C++ (for most code) and x86 assembler (for the finicky parts like context switching and IPC). Other than the basics, the groups could add whatever they wanted to their OS. Some groups wrote floppy drivers, network layers, advanced GUI features (like window managers), filesystems, whatever they wanted.

    Obviously this is overkill, but I don't think enough emphasis is put on operating systems and what they do, especially nowadays when "operating system" means "operating system + window manager + huge array of tools" to most users. Compilers need to be emphasized more, too, but that's a topic for another day.



  • @davidyorke said:

    Worth doing or read a book?  How about both? 

    Ray Ontko and Alexander Reeder have written such a program in Java as a companion to Tanenbaum's Modern Operating Systems (2nd Ed). It's called "MOSS" (Modern Operating System Simulator).  Theirs seems directed at specific areas of interest rather than being a general simulator.


    If thats the case then I need to bitch-slap my professor. She gave us probably the prequel to MOSS. I never wanted a general purpouse, but I wanted the students to have to write a scheduler, swapper, and pager algorithm along with the ability to track how efficient the algorithm is, and have targets of what is good for this class. Then later on other features can be added if the need arises.

     

    The MOSS definately solves all I wanted to do. The student does not seem to have to implement everything together. 

     

    If there are shortcommings to the MOSS maybe in that it does not tie everything together, that could be a good reason to make "the one"

     

    Edit: Looked at NACHOS, cool beans! Looks cool: thread simulators too... Maybe it should be NACOS in java with less "gotchas"?

     

     



  • @Nandurius said:

     

    I like your point, but as I noticed, my college may not have been up to the right standard of requiring students to work in groups on an OS. Hell we had problems when there were groups of 3 and they had to implement SOS something most could do alone, what wound up happening is one person did all the work (natural for groups). This was more of an undergrad project, I guess had this been a grad project I would have met some real tallent :).

     

    Edit: This is more than just "make it work" it had metrics assigned to it. The program had to "complete" meaning there was a heavy load and your algorithms had to meet the requirements. This also assumed that your interrupt handlers did not take up any time to execute.



  •  I see this thread going in two directions about the SOS idea.

    1. A mostly complete operating system with upgrades/optomizations to be made (MOSS/NACHOS).
    2. Build an OS from scratch to get the total picture and perhaps practice some design methods.

    I think both are really important.  There is a plethora of existing OS code out needs upgrading or maintenance.  Also, there is always new hardware coming down the pike which could possibly benefit from a clean-sheet approach to development, especially in limited resource embedded applications.

    I think CS and SE students would benefit from both approaches.  At least they should be given the option to pursue the one that they are more interested in.  Although I think some hiring managers might be put off by someone who only did the "from scratch" option.  It may be indicitive, in their minds, of a "wheel re-inventor". 



  • @davidyorke said:

    I think both are really important.
     

    I agree, and you'll have to pick what's best for your specific instance. Over here, we have lectures that are accompanied by weekly assignments (sometimes mandatory, sometimes optional.) I think that for a lecture on operating systems, the pre-build OS "Box of LEGO bricks" is the best choice, as it allows you to focus on a single concept at a time, and assign work that is independent of previous assignments.

    When you're building an OS from scratch, the above mentioned theory should already be known, as the focus will be on the actual hardware interface and "making that damn task switching work without corrupting registers" rather than "evaluating performance of different scheduling strategies." The "from scratch" approach also requires a LOT more time, why is why it's a "lab" here, meaning that it has a lot more time allocated to it than a lecture would.

    @davidyorke said:

    Although I think some hiring managers might be put off by someone who only did the "from scratch" option.  It may be indicitive, in their minds, of a "wheel re-inventor". 

    I'm going to have to disagree strongly here. This isn't re-inventing the wheel, nobody has any expectation of actually *using* the resulting operating system. It's merely a teaching tool -- a very effective one at that -- just like writing "hello world" programs, quicksort, heapsort, and other algorithms, or any of the other stuff you tend to do while studying computer science.

    I'm sure that anyone in a related field (embedded systems work, OS/driver development, etc) would appreciate that someone's already familiar with this specific kind of low level work.

     


Log in to reply